From frnkblk at iname.com Sat Sep 1 18:51:31 2018 From: frnkblk at iname.com (frnkblk at iname.com) Date: Sat, 1 Sep 2018 13:51:31 -0500 Subject: Service provider story about tracking down TCP RSTs Message-ID: <000901d44224$ccdf0210$669d0630$@iname.com> I want to share a little bit of our journey in tracking down the TCP RSTs that impacted some of our customers for almost ten weeks. Almost immediately after we turned up two new Arista border routers in late July we started receiving a trickle of complaints from customers regarding their inability to access certain websites (mostly B2B). All the packet captures showed the standard TCP SYN/SYN-ACK pair, then a TCP RST from the website after the client sent a TLS/SSL Client Hello. As the reports continued to come in, we built a Google Doc to keep track and it became clear that most of the sites were hosted by Incapsula/Imperva, but there were also a few by Sucuri and Fastly. Knowing that Incapsula provides DoS protection, we attempted to work with them (providing websites, source/destination IPs, traceroutes, and packet captures) to find out why their hosts were issuing our customers a TCP RST, but we made little progress. We moved some of the affected customers to different IP addresses but that didn't resolve the issue. We also asked our customer to work with the website to see if they would be willing to open a ticket with Incapsula. In the meantime, customers were getting frustrated! They couldn't visit Incapsula-hosted healthcare websites, financial firms, product dealers, etc. Over the weeks, a few of those customers purchased/borrowed different routers and some of those didn't have website issues anymore. And more than a few of them discovered that the websites worked fine from home or their mobile phone/hotspot, but not from their Internet connection with us. You can guess where they were applying pressure! That said, we didn't know why a small handful of companies, known for DoS protection, were issuing TCP RSTs to just some of our customers. Earlier this week we received four or five more websites from yet another affected customer, but most of those were with Fastly. By this time, we had been able to replicate the issue in our lab. Feeling desperate to make some tangible progress on this issue, I reached out to the Fastly NOC. In less than 12 hours they provided some helpful feedback, pointing out that a single traceroute to a Fastly site was hitting two of their POPs (they use anycast) and because they don't sync state between POPs the second POP would naturally issue a TCP RST (sidebar: fascinating blog article on Fastly's infrastructure here: https://www.fastly.com/blog/building-and-scaling-fastly-network-part-2-balan cing-requests). In subsequent email exchanges, the Fastly NOC suggested that it appeared that we were "spraying flows" (that is, packets related to single client session were egressing our network via different paths). Because Fastly is also present with us at an IX (though they weren't advertising their anycast IPs at the time), they suggested that we look at how our traffic egresses our network (IX versus transit) and our routers' outbound load-balancing/hashing schemes. The IX turned up to be a red herring, so I turned my attention to our transit. Each of our border routers has two BGP sessions over two circuits to transit provider POP A and two BGP sessions over two circuits to transit provider POP B, for a total of four BGP sessions per border router, a total of eight BGP sessions altogether. Starting with our core router, I confirmed that its ECMP hashing was consistent such that Fastly-bound traffic always went to border router 1 or border router 2. Then I looked at the ECMP hashing scheme on our border routers and noticed something unique - by default Arista also uses TTL: IPv4 hash fields: Source IPv4 Address is ON Protocol is ON Time-To-Live is ON Destination IPv4 Address is ON Since the source and destination IPs and protocol weren't changing, perhaps the TTL was not consistent? I opened the first packet trace in Wireshark and jackpot - the TTL value was 128 on the SYN but 127 on the TLS/SSL Client Hello. I adjusted the Arista's load-balancing profile not to use TTL and immediately my MTR in the background changed and all the sites on the lab machine that couldn't load before . were now loading. Fastly also pointed me to another article written by Joel Jaeggli (https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/) that discusses IPv6 flow labels - we removed that from the border routers' IPv6 hash fields, too. I reviewed the packet traces today and noticed that TTL values remained consistent at 128 *behind* the router CPE. In packet captures on the WAN interface of the router CPE I see that the SYN remains at 128, but the TLS/Client Hello is properly decremented to 127. So, it appears that some router CPE (and there were a variety of makes and models) are doing something special to certain packets and not decrementing the TTL. This explains why: * our customers had issues with all their devices behind their router CPE * the issue remained regardless of what public IP address their router CPE obtained via DHCP or was assigned * some customers who changed their router CPE didn't have the issue anymore - they got lucky with a router that doesn't adjust/reset the TTL * why customers who used our managed Wi-Fi router did not see the issue, because that model doesn't apparently manipulate the TTL, at least not in an inconsistent way. Lesson learned: review a device's hashing mechanism before going into production. For those interested, I have links to the packet traces below my signature, showing the inconsistent TTL values. Thanks again to the fantastic group of folk at the Fastly NOC who so ably pointed us in the right direction! Frank https://www.premieronline.net/~fbulk/example1.pcapng https://www.premieronline.net/~fbulk/example2.pcapng https://www.premieronline.net/~fbulk/example3.pcapng -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Sat Sep 1 20:00:36 2018 From: bill at herrin.us (William Herrin) Date: Sat, 1 Sep 2018 16:00:36 -0400 Subject: Service provider story about tracking down TCP RSTs In-Reply-To: <000901d44224$ccdf0210$669d0630$@iname.com> References: <000901d44224$ccdf0210$669d0630$@iname.com> Message-ID: On Sat, Sep 1, 2018 at 2:51 PM, wrote: > pointing out that a > single traceroute to a Fastly site was hitting two of their POPs (they use > anycast) and because they don’t sync state between POPs the second POP would > naturally issue a TCP RST (sidebar: fascinating blog article on Fastly’s > infrastructure here: > https://www.fastly.com/blog/building-and-scaling-fastly-network-part-2-balancing-requests). Oh for Pete's sake. If they're going to attempt Anycast TCP with a unicast protocol stack they should at least have the sense to suppress the RSTs. Better yet, do the job right and build an anycast TCP stack as described here: https://bill.herrin.us/network/anycasttcp.html Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From garrett at skjelstad.org Sat Sep 1 20:03:38 2018 From: garrett at skjelstad.org (Garrett Skjelstad) Date: Sat, 1 Sep 2018 13:03:38 -0700 Subject: Service provider story about tracking down TCP RSTs In-Reply-To: <000901d44224$ccdf0210$669d0630$@iname.com> References: <000901d44224$ccdf0210$669d0630$@iname.com> Message-ID: I would love this as a blog post to link folks that are not nanog members. -Garrett On Sat, Sep 1, 2018, 11:52 wrote: > I want to share a little bit of our journey in tracking down the TCP RSTs > that impacted some of our customers for almost ten weeks. > > > > Almost immediately after we turned up two new Arista border routers in > late July we started receiving a trickle of complaints from customers > regarding their inability to access certain websites (mostly B2B). All the > packet captures showed the standard TCP SYN/SYN-ACK pair, then a TCP RST > from the website after the client sent a TLS/SSL Client Hello. As the > reports continued to come in, we built a Google Doc to keep track and it > became clear that most of the sites were hosted by Incapsula/Imperva, but > there were also a few by Sucuri and Fastly. Knowing that Incapsula provides > DoS protection, we attempted to work with them (providing websites, > source/destination IPs, traceroutes, and packet captures) to find out why > their hosts were issuing our customers a TCP RST, but we made little > progress. We moved some of the affected customers to different IP addresses > but that didn’t resolve the issue. We also asked our customer to work with > the website to see if they would be willing to open a ticket with > Incapsula. In the meantime, customers were getting frustrated! They > couldn’t visit Incapsula-hosted healthcare websites, financial firms, > product dealers, etc. Over the weeks, a few of those customers > purchased/borrowed different routers and some of those didn’t have website > issues anymore. And more than a few of them discovered that the websites > worked fine from home or their mobile phone/hotspot, but not from their > Internet connection with us. You can guess where they were applying > pressure! That said, we didn’t know why a small handful of companies, known > for DoS protection, were issuing TCP RSTs to just some of our customers. > > > > Earlier this week we received four or five more websites from yet another > affected customer, but most of those were with Fastly. By this time, we had > been able to replicate the issue in our lab. Feeling desperate to make some > tangible progress on this issue, I reached out to the Fastly NOC. In less > than 12 hours they provided some helpful feedback, pointing out that a > single traceroute to a Fastly site was hitting two of their POPs (they use > anycast) and because they don’t sync state between POPs the second POP > would naturally issue a TCP RST (sidebar: fascinating blog article on > Fastly’s infrastructure here: > https://www.fastly.com/blog/building-and-scaling-fastly-network-part-2-balancing-requests). > In subsequent email exchanges, the Fastly NOC suggested that it appeared > that we were “spraying flows” (that is, packets related to single client > session were egressing our network via different paths). Because Fastly is > also present with us at an IX (though they weren’t advertising their > anycast IPs at the time), they suggested that we look at how our traffic > egresses our network (IX versus transit) and our routers’ outbound > load-balancing/hashing schemes. > > > > The IX turned up to be a red herring, so I turned my attention to our > transit. Each of our border routers has two BGP sessions over two circuits > to transit provider POP A and two BGP sessions over two circuits to transit > provider POP B, for a total of four BGP sessions per border router, a total > of eight BGP sessions altogether. Starting with our core router, I > confirmed that its ECMP hashing was consistent such that Fastly-bound > traffic always went to border router 1 or border router 2. Then I looked at > the ECMP hashing scheme on our border routers and noticed something unique > – by default Arista also uses TTL: > > > > IPv4 hash fields: > > Source IPv4 Address is ON > > Protocol is ON > > Time-To-Live is ON > > Destination IPv4 Address is ON > > > > Since the source and destination IPs and protocol weren’t changing, > perhaps the TTL was not consistent? I opened the first packet trace in > Wireshark and jackpot – the TTL value was 128 on the SYN but 127 on the > TLS/SSL Client Hello. I adjusted the Arista’s load-balancing profile not to > use TTL and immediately my MTR in the background changed and all the sites > on the lab machine that couldn’t load before … were now loading. > > > > Fastly also pointed me to another article written by Joel Jaeggli ( > https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/) that > discusses IPv6 flow labels – we removed that from the border routers’ IPv6 > hash fields, too. > > > > I reviewed the packet traces today and noticed that TTL values remained > consistent at 128 **behind** the router CPE. In packet captures on the > WAN interface of the router CPE I see that the SYN remains at 128, but the > TLS/Client Hello is properly decremented to 127. So, it appears that some > router CPE (and there were a variety of makes and models) are doing > something special to certain packets and not decrementing the TTL. > > This explains why: > > - our customers had issues with all their devices behind their router > CPE > - the issue remained regardless of what public IP address their router > CPE obtained via DHCP or was assigned > - some customers who changed their router CPE didn’t have the issue > anymore – they got lucky with a router that doesn’t adjust/reset the TTL > - why customers who used our managed Wi-Fi router did not see the > issue, because that model doesn’t apparently manipulate the TTL, at least > not in an inconsistent way. > > > > Lesson learned: review a device’s hashing mechanism before going into > production. > > > > For those interested, I have links to the packet traces below my > signature, showing the inconsistent TTL values. > > > > Thanks again to the fantastic group of folk at the Fastly NOC who so ably > pointed us in the right direction! > > > > Frank > > > > https://www.premieronline.net/~fbulk/example1.pcapng > > https://www.premieronline.net/~fbulk/example2.pcapng > > https://www.premieronline.net/~fbulk/example3.pcapng > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Sat Sep 1 20:54:07 2018 From: bill at herrin.us (William Herrin) Date: Sat, 1 Sep 2018 16:54:07 -0400 Subject: Service provider story about tracking down TCP RSTs In-Reply-To: References: <000901d44224$ccdf0210$669d0630$@iname.com> Message-ID: On Sat, Sep 1, 2018 at 4:00 PM, William Herrin wrote: > On Sat, Sep 1, 2018 at 2:51 PM, wrote: >> pointing out that a >> single traceroute to a Fastly site was hitting two of their POPs (they use >> anycast) and because they don’t sync state between POPs the second POP would >> naturally issue a TCP RST (sidebar: fascinating blog article on Fastly’s >> infrastructure here: >> https://www.fastly.com/blog/building-and-scaling-fastly-network-part-2-balancing-requests). > > Better yet, do the job right and build an anycast TCP stack as > described here: https://bill.herrin.us/network/anycasttcp.html BTW, for anyone concerned about an explosion in state management overhead, the TL;DR version is: the anycast node which first accepts the TCP connection encodes its identity in the TCP sequence number where all the other nodes can statelessly find it in the subsequent packets. The exhaustive details for how that actually works are covered in the paper at the URL above, which you'll have to read despite its length if you want to understand. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From ryan.landry at gmail.com Sat Sep 1 21:45:07 2018 From: ryan.landry at gmail.com (Ryan Landry) Date: Sat, 1 Sep 2018 14:45:07 -0700 Subject: Service provider story about tracking down TCP RSTs In-Reply-To: <000901d44224$ccdf0210$669d0630$@iname.com> References: <000901d44224$ccdf0210$669d0630$@iname.com> Message-ID: Glad we could help, Frank. On Sat, Sep 1, 2018 at 11:54 wrote: > I want to share a little bit of our journey in tracking down the TCP RSTs > that impacted some of our customers for almost ten weeks. > > > > Almost immediately after we turned up two new Arista border routers in > late July we started receiving a trickle of complaints from customers > regarding their inability to access certain websites (mostly B2B). All the > packet captures showed the standard TCP SYN/SYN-ACK pair, then a TCP RST > from the website after the client sent a TLS/SSL Client Hello. As the > reports continued to come in, we built a Google Doc to keep track and it > became clear that most of the sites were hosted by Incapsula/Imperva, but > there were also a few by Sucuri and Fastly. Knowing that Incapsula provides > DoS protection, we attempted to work with them (providing websites, > source/destination IPs, traceroutes, and packet captures) to find out why > their hosts were issuing our customers a TCP RST, but we made little > progress. We moved some of the affected customers to different IP addresses > but that didn’t resolve the issue. We also asked our customer to work with > the website to see if they would be willing to open a ticket with > Incapsula. In the meantime, customers were getting frustrated! They > couldn’t visit Incapsula-hosted healthcare websites, financial firms, > product dealers, etc. Over the weeks, a few of those customers > purchased/borrowed different routers and some of those didn’t have website > issues anymore. And more than a few of them discovered that the websites > worked fine from home or their mobile phone/hotspot, but not from their > Internet connection with us. You can guess where they were applying > pressure! That said, we didn’t know why a small handful of companies, known > for DoS protection, were issuing TCP RSTs to just some of our customers. > > > > Earlier this week we received four or five more websites from yet another > affected customer, but most of those were with Fastly. By this time, we had > been able to replicate the issue in our lab. Feeling desperate to make some > tangible progress on this issue, I reached out to the Fastly NOC. In less > than 12 hours they provided some helpful feedback, pointing out that a > single traceroute to a Fastly site was hitting two of their POPs (they use > anycast) and because they don’t sync state between POPs the second POP > would naturally issue a TCP RST (sidebar: fascinating blog article on > Fastly’s infrastructure here: > https://www.fastly.com/blog/building-and-scaling-fastly-network-part-2-balancing-requests). > In subsequent email exchanges, the Fastly NOC suggested that it appeared > that we were “spraying flows” (that is, packets related to single client > session were egressing our network via different paths). Because Fastly is > also present with us at an IX (though they weren’t advertising their > anycast IPs at the time), they suggested that we look at how our traffic > egresses our network (IX versus transit) and our routers’ outbound > load-balancing/hashing schemes. > > > > The IX turned up to be a red herring, so I turned my attention to our > transit. Each of our border routers has two BGP sessions over two circuits > to transit provider POP A and two BGP sessions over two circuits to transit > provider POP B, for a total of four BGP sessions per border router, a total > of eight BGP sessions altogether. Starting with our core router, I > confirmed that its ECMP hashing was consistent such that Fastly-bound > traffic always went to border router 1 or border router 2. Then I looked at > the ECMP hashing scheme on our border routers and noticed something unique > – by default Arista also uses TTL: > > > > IPv4 hash fields: > > Source IPv4 Address is ON > > Protocol is ON > > Time-To-Live is ON > > Destination IPv4 Address is ON > > > > Since the source and destination IPs and protocol weren’t changing, > perhaps the TTL was not consistent? I opened the first packet trace in > Wireshark and jackpot – the TTL value was 128 on the SYN but 127 on the > TLS/SSL Client Hello. I adjusted the Arista’s load-balancing profile not to > use TTL and immediately my MTR in the background changed and all the sites > on the lab machine that couldn’t load before … were now loading. > > > > Fastly also pointed me to another article written by Joel Jaeggli ( > https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/) that > discusses IPv6 flow labels – we removed that from the border routers’ IPv6 > hash fields, too. > > > > I reviewed the packet traces today and noticed that TTL values remained > consistent at 128 **behind** the router CPE. In packet captures on the > WAN interface of the router CPE I see that the SYN remains at 128, but the > TLS/Client Hello is properly decremented to 127. So, it appears that some > router CPE (and there were a variety of makes and models) are doing > something special to certain packets and not decrementing the TTL. > > This explains why: > > - our customers had issues with all their devices behind their router > CPE > - the issue remained regardless of what public IP address their router > CPE obtained via DHCP or was assigned > - some customers who changed their router CPE didn’t have the issue > anymore – they got lucky with a router that doesn’t adjust/reset the TTL > - why customers who used our managed Wi-Fi router did not see the > issue, because that model doesn’t apparently manipulate the TTL, at least > not in an inconsistent way. > > > > Lesson learned: review a device’s hashing mechanism before going into > production. > > > > For those interested, I have links to the packet traces below my > signature, showing the inconsistent TTL values. > > > > Thanks again to the fantastic group of folk at the Fastly NOC who so ably > pointed us in the right direction! > > > > Frank > > > > https://www.premieronline.net/~fbulk/example1.pcapng > > https://www.premieronline.net/~fbulk/example2.pcapng > > https://www.premieronline.net/~fbulk/example3.pcapng > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ler762 at gmail.com Sat Sep 1 22:11:26 2018 From: ler762 at gmail.com (Lee) Date: Sat, 1 Sep 2018 18:11:26 -0400 Subject: Service provider story about tracking down TCP RSTs In-Reply-To: References: <000901d44224$ccdf0210$669d0630$@iname.com> Message-ID: On 9/1/18, William Herrin wrote: > On Sat, Sep 1, 2018 at 4:00 PM, William Herrin wrote: >> On Sat, Sep 1, 2018 at 2:51 PM, wrote: >>> pointing out that a >>> single traceroute to a Fastly site was hitting two of their POPs (they >>> use >>> anycast) and because they don’t sync state between POPs the second POP >>> would >>> naturally issue a TCP RST (sidebar: fascinating blog article on Fastly’s >>> infrastructure here: >>> https://www.fastly.com/blog/building-and-scaling-fastly-network-part-2-balancing-requests). >> >> Better yet, do the job right and build an anycast TCP stack as >> described here: https://bill.herrin.us/network/anycasttcp.html > > BTW, for anyone concerned about an explosion in state management > overhead, the TL;DR version is: the anycast node which first accepts > the TCP connection encodes its identity in the TCP sequence number > where all the other nodes can statelessly find it in the subsequent > packets. The exhaustive details for how that actually works are > covered in the paper at the URL above, which you'll have to read > despite its length if you want to understand. An explosion in state management would be the least of my worries :) I got as far as your Third hook: and thought of this https://www.jwz.org/doc/worse-is-better.html I had it much easier with anycast in an enterprise setting. With anycast servers in data centers A & B, just make sure no site has an equal cost path to A and B. Any link/ router/ whatever failure & the user can just re-try. Lee From eric.kuhnke at gmail.com Sat Sep 1 23:39:41 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Sat, 1 Sep 2018 16:39:41 -0700 Subject: TekSavvy (Canada) contact In-Reply-To: <7C428EA0-7865-4A90-803B-5C3770CE0488@paulstewart.org> References: <1105410579.1375.1535580322400.JavaMail.mhammett@ThunderFuck> <9F19E1E3AA18DC32.0789C402-E66B-4F0E-8692-F74A9915AE84@mail.outlook.com> <7C428EA0-7865-4A90-803B-5C3770CE0488@paulstewart.org> Message-ID: Hey all, It was not my intention to cause any unwarranted concern related to the TekSavvy network. There are zero issues with their network. Every service I have ever purchased from them is rock solid and reliable. I'm in contact with Paul and others there directly. The topic of discussion is related to a third party copper last mile access network in a specific geographic region of Canada. On Thu, Aug 30, 2018, 5:16 AM Paul Stewart wrote: > Folks – please do **not** request “clueful neteng point of contact” on > the list if you are really looking to place an order for residential > service. Thanks … > > > > Paul > > > > > > *From: *NANOG on behalf of "paul at paulstewart.org" > > *Date: *Wednesday, August 29, 2018 at 6:09 PM > *To: *Mike Hammett > *Cc: *"nanog at nanog.org list" > *Subject: *Re: TekSavvy (Canada) contact > > > > Thnx all - already reached out > > > > Paul > > > > Get Outlook for iOS > > > > On Wed, Aug 29, 2018 at 6:05 PM -0400, "Mike Hammett" > wrote: > > "Paul Stewart" > > He's on AFMUG too. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > [image: Image removed by sender.] [image: > Image removed by sender.] > [image: > Image removed by sender.] > [image: > Image removed by sender.] > Midwest Internet Exchange > [image: Image removed by sender.] [image: > Image removed by sender.] > [image: Image > removed by sender.] > The Brothers WISP > [image: Image removed by sender.] > [image: Image removed by > sender.] > ------------------------------ > > *From: *"Eric Kuhnke" > *To: *"nanog at nanog.org list" > *Sent: *Wednesday, August 29, 2018 4:48:48 PM > *Subject: *TekSavvy (Canada) contact > > I'm looking for a clueful neteng point of contact at TekSavvy. Please > contact me off-list. Thanks! > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From baldur.norddahl at gmail.com Sun Sep 2 00:18:08 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 2 Sep 2018 02:18:08 +0200 Subject: automatic rtbh trigger using flow data In-Reply-To: <20180831151535.GB9210@bamboo.slabnet.com> References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> <60BB16CA-A829-4B8A-BFC2-47FAD7D105BE@arbor.net> <20180831151535.GB9210@bamboo.slabnet.com> Message-ID: fre. 31. aug. 2018 17.16 skrev Hugo Slabbert : > > > I would love an upstream that accepts flowspec routes to get granular > about > drops and to basically push "stateless ACLs" upstream. > > _keeps dreaming_ > > > We just need a signal to drop UDP for a prefix. The same as RTBH but only for UDP. This would prevent all volumetric attacks without the end user being cut off completely. Besides from some games, VPN and VoIP, they would have an almost completely normal internet experience. DNS would go through the ISP servers and only be affected if the user is using a third party service. Regards Baldur -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Sun Sep 2 00:38:51 2018 From: bill at herrin.us (William Herrin) Date: Sat, 1 Sep 2018 20:38:51 -0400 Subject: Service provider story about tracking down TCP RSTs In-Reply-To: References: <000901d44224$ccdf0210$669d0630$@iname.com> Message-ID: On Sat, Sep 1, 2018 at 6:11 PM, Lee wrote: > On 9/1/18, William Herrin wrote: >> On Sat, Sep 1, 2018 at 4:00 PM, William Herrin wrote: >>> Better yet, do the job right and build an anycast TCP stack as >>> described here: https://bill.herrin.us/network/anycasttcp.html > > An explosion in state management would be the least of my worries :) > I got as far as your Third hook: and thought of this > https://www.jwz.org/doc/worse-is-better.html Hi Lee, On a brief tangent: Geographic routing would drastically simplify the Internet core, reducing both cost and complexity. You'd need to carry only nearby specific routes and a few broad aggregates for destinations far away. It will never be implemented, never, because no cross-ocean carriers are willing to have their bandwidth stolen when the algorithm decides it likes their path better than a paid one. Even though the algorithm gets the packets where they're going, and does so simply, it does so in a way that's too often incorrect. Then again, I don't really understand the MIT/New Jersey argument in Richard's worse-is-better story. The MIT guy says that a routine should handle a common non-fatal exception. The Jersey guy says that it's ok for the routine to return a try-again error and expect the caller to handle it. Since its trivial to build another layer that calls the routine in a loop until it returns success or a fatal error, it's more a philosophical argument than a practical one. As long as a correct result is consistently achieved in both cases, what's the difference? Richard characterized the Jersey argument as, "It is slightly better to be simple than correct." I just don't see that in the Jersey argument. Every component must be correct. The system of components as a whole must be complete. It's slightly better for a component to be simple than complete. That's the argument I read and it makes sense to me. Honestly, the idea that software is good enough even with known corner cases that do something incorrect... I don't know how that survives in a world where security-conscious programming is not optional. > I had it much easier with anycast in an enterprise setting. With > anycast servers in data centers A & B, just make sure no site has an > equal cost path to A and B. Any link/ router/ whatever failure & the > user can just re-try. You've delicately balanced your network to achieve the principle that even when routing around failures the anycast sites are not equidistant from any other site. That isn't simplicity. It's complexity hidden in the expert selection of magic numbers. Even were that achievable in a network as chaotic as the Internet, is it simpler than four trivial tweaks to the TCP stack plus a modestly complex but fully automatic user-space program that correctly reroutes the small percentage of packets that went astray? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From Ryan.Hamel at quadranet.com Sun Sep 2 00:39:40 2018 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Sun, 2 Sep 2018 00:39:40 +0000 Subject: automatic rtbh trigger using flow data In-Reply-To: References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> <60BB16CA-A829-4B8A-BFC2-47FAD7D105BE@arbor.net> <20180831151535.GB9210@bamboo.slabnet.com> Message-ID: <51883ca42e664eaab18fa6b1c8f41dd8@LAX-MBX01.quadranet.local> No ISP is in the business of filtering traffic unless the client pays the hefty fee since someone still has to tank the attack. I also don’t think there is destination prefix IP filtering in flowspec, which could seriously cause problems. From: NANOG On Behalf Of Baldur Norddahl Sent: Saturday, September 01, 2018 5:18 PM To: nanog at nanog.org Subject: Re: automatic rtbh trigger using flow data fre. 31. aug. 2018 17.16 skrev Hugo Slabbert >: I would love an upstream that accepts flowspec routes to get granular about drops and to basically push "stateless ACLs" upstream. _keeps dreaming_ We just need a signal to drop UDP for a prefix. The same as RTBH but only for UDP. This would prevent all volumetric attacks without the end user being cut off completely. Besides from some games, VPN and VoIP, they would have an almost completely normal internet experience. DNS would go through the ISP servers and only be affected if the user is using a third party service. Regards Baldur -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdobbins at arbor.net Sun Sep 2 03:02:43 2018 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 02 Sep 2018 10:02:43 +0700 Subject: automatic rtbh trigger using flow data In-Reply-To: <000f01d44159$649d6b40$2dd841c0$@gvtc.com> References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> <62e299ab-3b58-515b-81a7-a95101616cba@gmail.com> <000f01d44159$649d6b40$2dd841c0$@gvtc.com> Message-ID: <9ECE77CE-6198-4758-B0E5-6E94DACAE6CD@arbor.net> On 1 Sep 2018, at 1:35, Aaron Gould wrote: > I may mark internet-sourced-udp with a certain marking dscp/exp so > that as it travels through my internet > network, it will be the first to get dropped (? Wred ? work well for > udp?) during congestion when an attack gets through You can use flow telemetry analysis to look at the UDP non-initial fragments destined for any access networks under your control; you'll likely see that they comprise a tiny portion of the overall traffic mix, and they're most commonly associated with large DNS answers. Once you've determined the numbers, you can police down the non-initial fragments destined for the access networks you control (don't do this on transit traffic!) to whatever small percentage makes the most sense, with a bit of extra headroom. 1% of link bandwidth works for several operators. In that QoS policy, you exempt well-known/well-run open DNS recursor farms like Google DNS, OpenDNS, et. al. (and possibly your own, depending on your topology, etc.), and any other legitimate source CIDRs which generate appreciable amounts of non-initial fragments. When a reflection/amplification attack which involves non-initial fragments hits, the QoS policy will sink a significant proportion of the attack. It doesn't help with your peering links, but keeps the traffic off your core and off the large network(s). Again, don't apply this across-the-board; only do it for access networks within your span of administrative control. > * btw, what can you experts tell me about tcp-based volumetric > attacks... TCP reflection/amplification. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Sun Sep 2 03:05:19 2018 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 02 Sep 2018 10:05:19 +0700 Subject: automatic rtbh trigger using flow data In-Reply-To: <07fa1a4b08284f978a88f670ba066d90@SC58MEXGP014.CORP.CHARTERCOM.com> References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> <62e299ab-3b58-515b-81a7-a95101616cba@gmail.com> <07fa1a4b08284f978a88f670ba066d90@SC58MEXGP014.CORP.CHARTERCOM.com> Message-ID: <17895CCE-5627-429B-B734-FC0A536BE605@arbor.net> On 1 Sep 2018, at 1:20, Lotia, Pratik M wrote: > Arbor report mentions volumetric attacks using DNS, NTP form 75+% of > the attacks. I'm well aware of what's mentioned in the Arbor report, thanks! ;> > Then QoSing certain ports and protocols is the best way to start with. The point is that when applying broad policies of this nature, one must be very conservative, else one can cause larger problems on a macro scale. Internet ateriosclerosis is a significant issue. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Sun Sep 2 03:09:32 2018 From: rdobbins at arbor.net (Roland Dobbins) Date: Sun, 02 Sep 2018 10:09:32 +0700 Subject: automatic rtbh trigger using flow data In-Reply-To: <20180831184304.GC9210@bamboo.slabnet.com> References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> <62e299ab-3b58-515b-81a7-a95101616cba@gmail.com> <000f01d44159$649d6b40$2dd841c0$@gvtc.com> <20180831184304.GC9210@bamboo.slabnet.com> Message-ID: <057F473C-8200-4AFF-8230-7DEDC2F51C90@arbor.net> On 1 Sep 2018, at 1:43, Hugo Slabbert wrote: > Generally on the TCP side you can try SYN or ACK floods, but you're > not going to get an amplified reflection. Actually, TCP reflection/amplification has been on the increase; the attacker is guaranteed at least 4:1 amplification in most circumstances, the number of reflectors/amplifiers is for all practical purposes infinite, and they're mostly legitimate, non-broken services/applications. And as always, it's important to note that with all reflection/amplification attacks, the root of the issue is the lack of universal source-address validation (SAV). Without the ability to spoof, there would be no reflection/amplification attacks. ----------------------------------- Roland Dobbins From hugo at slabnet.com Sun Sep 2 03:19:00 2018 From: hugo at slabnet.com (Hugo Slabbert) Date: Sat, 1 Sep 2018 20:19:00 -0700 Subject: automatic rtbh trigger using flow data In-Reply-To: <057F473C-8200-4AFF-8230-7DEDC2F51C90@arbor.net> References: <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> <62e299ab-3b58-515b-81a7-a95101616cba@gmail.com> <000f01d44159$649d6b40$2dd841c0$@gvtc.com> <20180831184304.GC9210@bamboo.slabnet.com> <057F473C-8200-4AFF-8230-7DEDC2F51C90@arbor.net> Message-ID: <20180902031900.GD9210@bamboo.slabnet.com> On Sun 2018-Sep-02 10:09:32 +0700, Roland Dobbins wrote: > >On 1 Sep 2018, at 1:43, Hugo Slabbert wrote: > >>Generally on the TCP side you can try SYN or ACK floods, but you're >>not going to get an amplified reflection. > >Actually, TCP reflection/amplification has been on the increase; the >attacker is guaranteed at least 4:1 amplification in most >circumstances, the number of reflectors/amplifiers is for all >practical purposes infinite, and they're mostly legitimate, >non-broken services/applications. Fair. I guess in terms of common reflect/amp vector at $dayjob we just see UDP-based significantly more frequently on large volumetric attacks given the amp factor on some vectors is so huge. Some relevant reading I need to revisit: https://www.usenix.org/sites/default/files/conference/protected-files/woot14_slides_kuhrer.pdf https://www.usenix.org/system/files/conference/woot14/woot14-kuhrer.pdf >And as always, it's important to note that with all >reflection/amplification attacks, the root of the issue is the lack of >universal source-address validation (SAV). Without the ability to spoof, >there would be no reflection/amplification attacks. ACK, pun intended. >----------------------------------- >Roland Dobbins -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From hugo at slabnet.com Sun Sep 2 03:24:39 2018 From: hugo at slabnet.com (Hugo Slabbert) Date: Sat, 1 Sep 2018 20:24:39 -0700 Subject: automatic rtbh trigger using flow data In-Reply-To: <51883ca42e664eaab18fa6b1c8f41dd8@LAX-MBX01.quadranet.local> References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> <60BB16CA-A829-4B8A-BFC2-47FAD7D105BE@arbor.net> <20180831151535.GB9210@bamboo.slabnet.com> <51883ca42e664eaab18fa6b1c8f41dd8@LAX-MBX01.quadranet.local> Message-ID: <20180902032439.GE9210@bamboo.slabnet.com> On Sun 2018-Sep-02 00:39:40 +0000, Ryan Hamel wrote: >No ISP is in the business of filtering traffic unless the client pays the >hefty fee since someone still has to tank the attack. If I can tag an RTBH community on a /32, what's the additional lost revenue in letting me be more granular and get down to the specific flows I want dropped? "drop all traffic to x/32" would drop *more* traffic than "drop any traffic from address y to x/32, protocol TCP, port n". >I also don’t think there is destination prefix IP filtering in flowspec, >which could seriously cause problems. What now? Unless I'm misunderstanding what you're saying, it's right in the spec[1]: A flow specification NLRI must be validated such that it is considered feasible if and only if: a) The originator of the flow specification matches the originator of the best-match unicast route for the destination prefix embedded in the flow specification. b) There are no more specific unicast routes, when compared with the flow destination prefix, that have been received from a different neighboring AS than the best-match unicast route, which has been determined in step a). By originator of a BGP route, we mean either the BGP originator path attribute, as used by route reflection, or the transport address of the BGP peer, if this path attribute is not present. The underlying concept is that the neighboring AS that advertises the best unicast route for a destination is allowed to advertise flow- spec information that conveys a more or equally specific destination prefix. Thus, as long as there are no more specific unicast routes, received from a different neighboring AS, which would be affected by that filtering rule. The neighboring AS is the immediate destination of the traffic described by the flow specification. If it requests these flows to be dropped, that request can be honored without concern that it represents a denial of service in itself. Supposedly, the traffic is being dropped by the downstream autonomous system, and there is no added value in carrying the traffic to it. -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal [1] https://tools.ietf.org/html/rfc5575 > >From: NANOG On Behalf Of Baldur Norddahl >Sent: Saturday, September 01, 2018 5:18 PM >To: nanog at nanog.org >Subject: Re: automatic rtbh trigger using flow data > > >fre. 31. aug. 2018 17.16 skrev Hugo Slabbert >: > > >I would love an upstream that accepts flowspec routes to get granular about >drops and to basically push "stateless ACLs" upstream. > >_keeps dreaming_ > > >We just need a signal to drop UDP for a prefix. The same as RTBH but only for UDP. This would prevent all volumetric attacks without the end user being cut off completely. > >Besides from some games, VPN and VoIP, they would have an almost completely normal internet experience. DNS would go through the ISP servers and only be affected if the user is using a third party service. > >Regards > >Baldur > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From michel.py at tsisemi.com Sun Sep 2 04:54:56 2018 From: michel.py at tsisemi.com (Michel Py) Date: Sun, 2 Sep 2018 04:54:56 +0000 Subject: automatic rtbh trigger using flow data In-Reply-To: <51883ca42e664eaab18fa6b1c8f41dd8@LAX-MBX01.quadranet.local> References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> <60BB16CA-A829-4B8A-BFC2-47FAD7D105BE@arbor.net> <20180831151535.GB9210@bamboo.slabnet.com> <51883ca42e664eaab18fa6b1c8f41dd8@LAX-MBX01.quadranet.local> Message-ID: > Roland Dobbins wrote : > I'm well aware of what's mentioned in the Arbor report, thanks! I would not have guessed :P > Ryan Hamel wrote : > No ISP is in the business of filtering traffic unless the client pays the hefty fee since someone still has to tank the atack. I agree. In the end, it tends to favor who has the biggest one. I meant the biggest bandwidth, of course. I the foreseeable future, no blacklist system is going to replace what Arbor and consorts can provide : a pipe big enough to either route the DDOS attack to null0 or even better route it to somewhere it can be analyzed further. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From ler762 at gmail.com Sun Sep 2 06:38:57 2018 From: ler762 at gmail.com (Lee) Date: Sun, 2 Sep 2018 02:38:57 -0400 Subject: Service provider story about tracking down TCP RSTs In-Reply-To: References: <000901d44224$ccdf0210$669d0630$@iname.com> Message-ID: On 9/1/18, William Herrin wrote: > On Sat, Sep 1, 2018 at 6:11 PM, Lee wrote: >> On 9/1/18, William Herrin wrote: >>> On Sat, Sep 1, 2018 at 4:00 PM, William Herrin wrote: >>>> Better yet, do the job right and build an anycast TCP stack as >>>> described here: https://bill.herrin.us/network/anycasttcp.html >> >> An explosion in state management would be the least of my worries :) >> I got as far as your Third hook: and thought of this >> https://www.jwz.org/doc/worse-is-better.html > > Hi Lee, > > On a brief tangent: Geographic routing would drastically simplify the > Internet core, reducing both cost and complexity. You'd need to carry > only nearby specific routes and a few broad aggregates for > destinations far away. It will never be implemented, never, because no > cross-ocean carriers are willing to have their bandwidth stolen when > the algorithm decides it likes their path better than a paid one. Even > though the algorithm gets the packets where they're going, and does so > simply, it does so in a way that's too often incorrect. > > Then again, I don't really understand the MIT/New Jersey argument in > Richard's worse-is-better story. The "New Jersey" description is more of a caricature than a valid description: "I have intentionally caricatured the worse-is-better philosophy to convince you that it is obviously a bad philosophy and that the New Jersey approach is a bad approach." I mentally did a 's/New Jersey/Microsoft/' and it made a lot more sense. > The MIT guy says that a routine > should handle a common non-fatal exception. The Jersey guy says that > it's ok for the routine to return a try-again error and expect the > caller to handle it. Since its trivial to build another layer that > calls the routine in a loop until it returns success or a fatal error, > it's more a philosophical argument than a practical one. As long as a > correct result is consistently achieved in both cases, what's the > difference? That it's not always a trivial matter to build another layer. That your retry layer needs at least a counter or timeout value so it doesn't retry forever & those values need to be user configurable, so the re-try layer isn't quite as trivial as it appears at first blush. > Richard characterized the Jersey argument as, "It is slightly better > to be simple than correct." I just don't see that in the Jersey > argument. Every component must be correct. The system of components as > a whole must be complete. It's slightly better for a component to be > simple than complete. That's the argument I read and it makes sense to > me. Yes, I did a lot of interpreting also. Then I hit on s/New Jersey/Microsoft/ and it made a lot more sense to me. > Honestly, the idea that software is good enough even with known corner > cases that do something incorrect... I don't know how that survives in > a world where security-conscious programming is not optional. Agreed. I substituted "soft-fail or fail-closed: user has to retry" for doing something incorrect. >> I had it much easier with anycast in an enterprise setting. With >> anycast servers in data centers A & B, just make sure no site has an >> equal cost path to A and B. Any link/ router/ whatever failure & the >> user can just re-try. > > You've delicately balanced your network to achieve the principle that > even when routing around failures the anycast sites are not > equidistant from any other site. That isn't simplicity. It's > complexity hidden in the expert selection of magic numbers. ^shrug^ it seemed simple to me. And it was real easy to explain, which is why I thought of that "worse is better" paper. I took the New Jersey approach & did what was basically a hack. You took the MIT approach and created a general solution .. which is not so easy to explain :) > Even were that achievable in a network as chaotic as the Internet, is it simpler > than four trivial tweaks to the TCP stack plus a modestly complex but > fully automatic user-space program that correctly reroutes the small > percentage of packets that went astray? Your four trivial tweaks to the TCP stack are kernel patches - right? Which seems not at all trivial to me, but if you've got a group of people that can support & maintain that - good for you! Regards Lee From jwbensley at gmail.com Sun Sep 2 08:24:05 2018 From: jwbensley at gmail.com (James Bensley) Date: Sun, 2 Sep 2018 09:24:05 +0100 Subject: Service provider story about tracking down TCP RSTs In-Reply-To: References: <000901d44224$ccdf0210$669d0630$@iname.com> Message-ID: On Sat, 1 Sep 2018 at 21:06, Garrett Skjelstad wrote: > > I would love this as a blog post to link folks that are not nanog members. > > -Garrett Hi Garrett, It is available via the NANOG list archives: https://mailman.nanog.org/pipermail/nanog/2018-September/096871.html I've shared this story to non-list member using that URL. Thanks for the write up Frank! Cheers, James. From baldur.norddahl at gmail.com Sun Sep 2 08:42:09 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 2 Sep 2018 10:42:09 +0200 Subject: automatic rtbh trigger using flow data In-Reply-To: <51883ca42e664eaab18fa6b1c8f41dd8@LAX-MBX01.quadranet.local> References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> <60BB16CA-A829-4B8A-BFC2-47FAD7D105BE@arbor.net> <20180831151535.GB9210@bamboo.slabnet.com> <51883ca42e664eaab18fa6b1c8f41dd8@LAX-MBX01.quadranet.local> Message-ID: This is not true. Some of our transits do RTBH for free. For example Cogent. They will not do FlowSpec. Maybe their equipment can not do it or for some other reason. However RTBH is a simple routing hack that can be implemented on any router. The traffic is dropped right at the edge and is never transported on the transit provider network. In that sense it also protects the transit network. RTBH only for UDP would also be a very simple hack on many routers. It might not be FlowSpec, but it may have most of the benefit, in a much simplified way. Regards Baldur søn. 2. sep. 2018 02.39 skrev Ryan Hamel : > No ISP is in the business of filtering traffic unless the client pays the > hefty fee since someone still has to tank the attack. > > > > I also don’t think there is destination prefix IP filtering in flowspec, > which could seriously cause problems. > > > > *From:* NANOG *On Behalf Of *Baldur Norddahl > *Sent:* Saturday, September 01, 2018 5:18 PM > *To:* nanog at nanog.org > *Subject:* Re: automatic rtbh trigger using flow data > > > > > > fre. 31. aug. 2018 17.16 skrev Hugo Slabbert : > > > > I would love an upstream that accepts flowspec routes to get granular > about > drops and to basically push "stateless ACLs" upstream. > > _keeps dreaming_ > > > > > > We just need a signal to drop UDP for a prefix. The same as RTBH but only > for UDP. This would prevent all volumetric attacks without the end user > being cut off completely. > > > > Besides from some games, VPN and VoIP, they would have an almost > completely normal internet experience. DNS would go through the ISP servers > and only be affected if the user is using a third party service. > > > > Regards > > > > Baldur > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ryan.Hamel at quadranet.com Sun Sep 2 09:07:14 2018 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Sun, 2 Sep 2018 09:07:14 +0000 Subject: automatic rtbh trigger using flow data In-Reply-To: References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> <60BB16CA-A829-4B8A-BFC2-47FAD7D105BE@arbor.net> <20180831151535.GB9210@bamboo.slabnet.com> <51883ca42e664eaab18fa6b1c8f41dd8@LAX-MBX01.quadranet.local> Message-ID: <693fb731e7184bd49858d3d82bf0b7ed@LAX-MBX01.quadranet.local> Baldur, Modifying the routing table with a next-hop change from a community, is different than having a line card filtering packets at layer 4, of course most if not all carriers will support it. Instead of doing normal TCAM route lookups, you’re getting into packet inspection territory, which is something completely different. Just quickly reading the ASR 9K documentation, it can only support 3K rules per system. Juniper – 8K, Alcatel-Lucent – 512. That’s pretty low considering I can put many /32s into a routing table very easily and without hassle. As I said before, no ISP is going to offer such filtering services for free when DDoS mitigation is a cash cow. Ryan Hamel From: NANOG On Behalf Of Baldur Norddahl Sent: Sunday, September 02, 2018 1:42 AM To: nanog at nanog.org Subject: Re: automatic rtbh trigger using flow data This is not true. Some of our transits do RTBH for free. For example Cogent. They will not do FlowSpec. Maybe their equipment can not do it or for some other reason. However RTBH is a simple routing hack that can be implemented on any router. The traffic is dropped right at the edge and is never transported on the transit provider network. In that sense it also protects the transit network. RTBH only for UDP would also be a very simple hack on many routers. It might not be FlowSpec, but it may have most of the benefit, in a much simplified way. Regards Baldur søn. 2. sep. 2018 02.39 skrev Ryan Hamel >: No ISP is in the business of filtering traffic unless the client pays the hefty fee since someone still has to tank the attack. I also don’t think there is destination prefix IP filtering in flowspec, which could seriously cause problems. From: NANOG > On Behalf Of Baldur Norddahl Sent: Saturday, September 01, 2018 5:18 PM To: nanog at nanog.org Subject: Re: automatic rtbh trigger using flow data fre. 31. aug. 2018 17.16 skrev Hugo Slabbert >: I would love an upstream that accepts flowspec routes to get granular about drops and to basically push "stateless ACLs" upstream. _keeps dreaming_ We just need a signal to drop UDP for a prefix. The same as RTBH but only for UDP. This would prevent all volumetric attacks without the end user being cut off completely. Besides from some games, VPN and VoIP, they would have an almost completely normal internet experience. DNS would go through the ISP servers and only be affected if the user is using a third party service. Regards Baldur -------------- next part -------------- An HTML attachment was scrubbed... URL: From baldur.norddahl at gmail.com Sun Sep 2 09:45:29 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sun, 2 Sep 2018 11:45:29 +0200 Subject: automatic rtbh trigger using flow data In-Reply-To: <693fb731e7184bd49858d3d82bf0b7ed@LAX-MBX01.quadranet.local> References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> <60BB16CA-A829-4B8A-BFC2-47FAD7D105BE@arbor.net> <20180831151535.GB9210@bamboo.slabnet.com> <51883ca42e664eaab18fa6b1c8f41dd8@LAX-MBX01.quadranet.local> <693fb731e7184bd49858d3d82bf0b7ed@LAX-MBX01.quadranet.local> Message-ID: I would redirect the packet to a VRF with one global drop UDP ACL. That scales perfectly. There is probably many ways to implement such a feature. søn. 2. sep. 2018 11.07 skrev Ryan Hamel : > Baldur, > > > > Modifying the routing table with a next-hop change from a community, is > different than having a line card filtering packets at layer 4, of course > most if not all carriers will support it. Instead of doing normal TCAM > route lookups, you’re getting into packet inspection territory, which is > something completely different. > > > > Just quickly reading the ASR 9K documentation, it can only support 3K > rules per system. Juniper – 8K, Alcatel-Lucent – 512. That’s pretty low > considering I can put many /32s into a routing table very easily and > without hassle. > > > > As I said before, no ISP is going to offer such filtering services for > free when DDoS mitigation is a cash cow. > > > > Ryan Hamel > > > > *From:* NANOG *On Behalf Of *Baldur Norddahl > *Sent:* Sunday, September 02, 2018 1:42 AM > *To:* nanog at nanog.org > *Subject:* Re: automatic rtbh trigger using flow data > > > > This is not true. Some of our transits do RTBH for free. For example > Cogent. > > > > They will not do FlowSpec. Maybe their equipment can not do it or for some > other reason. > > > > However RTBH is a simple routing hack that can be implemented on any > router. The traffic is dropped right at the edge and is never transported > on the transit provider network. In that sense it also protects the transit > network. > > > > RTBH only for UDP would also be a very simple hack on many routers. > > > > It might not be FlowSpec, but it may have most of the benefit, in a much > simplified way. > > > > Regards > > > > Baldur > > > > > > søn. 2. sep. 2018 02.39 skrev Ryan Hamel : > > No ISP is in the business of filtering traffic unless the client pays the > hefty fee since someone still has to tank the attack. > > > > I also don’t think there is destination prefix IP filtering in flowspec, > which could seriously cause problems. > > > > *From:* NANOG *On Behalf Of *Baldur Norddahl > *Sent:* Saturday, September 01, 2018 5:18 PM > *To:* nanog at nanog.org > *Subject:* Re: automatic rtbh trigger using flow data > > > > > > fre. 31. aug. 2018 17.16 skrev Hugo Slabbert : > > > > I would love an upstream that accepts flowspec routes to get granular > about > drops and to basically push "stateless ACLs" upstream. > > _keeps dreaming_ > > > > > > We just need a signal to drop UDP for a prefix. The same as RTBH but only > for UDP. This would prevent all volumetric attacks without the end user > being cut off completely. > > > > Besides from some games, VPN and VoIP, they would have an almost > completely normal internet experience. DNS would go through the ISP servers > and only be affected if the user is using a third party service. > > > > Regards > > > > Baldur > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn at mork.no Sun Sep 2 10:06:24 2018 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Sun, 02 Sep 2018 12:06:24 +0200 Subject: Service provider story about tracking down TCP RSTs In-Reply-To: (William Herrin's message of "Sat, 1 Sep 2018 16:54:07 -0400") References: <000901d44224$ccdf0210$669d0630$@iname.com> Message-ID: <871sac5i3j.fsf@miraculix.mork.no> William Herrin writes: > BTW, for anyone concerned about an explosion in state management > overhead, the TL;DR version is: the anycast node which first accepts > the TCP connection encodes its identity in the TCP sequence number > where all the other nodes can statelessly find it in the subsequent > packets. I didn't see a security section in your document. Did you consider the side effects of this sequence number abuse? Bjørn From nanog at jack.fr.eu.org Sun Sep 2 10:20:31 2018 From: nanog at jack.fr.eu.org (nanog at jack.fr.eu.org) Date: Sun, 2 Sep 2018 12:20:31 +0200 Subject: Service provider story about tracking down TCP RSTs In-Reply-To: References: <000901d44224$ccdf0210$669d0630$@iname.com> Message-ID: <5B8BB96F.1040406@jack.fr.eu.org> On 09/02/2018 10:24 AM, James Bensley wrote: > It is available via the NANOG list archives: > https://mailman.nanog.org/pipermail/nanog/2018-September/096871.html But why did the TLS Hello has a TTL lower that the TCP Syn ? Do you have any information on that ? From bill at herrin.us Sun Sep 2 10:40:10 2018 From: bill at herrin.us (William Herrin) Date: Sun, 2 Sep 2018 06:40:10 -0400 Subject: Service provider story about tracking down TCP RSTs In-Reply-To: <871sac5i3j.fsf@miraculix.mork.no> References: <000901d44224$ccdf0210$669d0630$@iname.com> <871sac5i3j.fsf@miraculix.mork.no> Message-ID: On Sun, Sep 2, 2018 at 6:06 AM, Bjørn Mork wrote: > William Herrin writes: >> https://bill.herrin.us/network/anycasttcp.html > > I didn't see a security section in your document. Did you consider the > side effects of this sequence number abuse? Hi Bjørn, In the "issues and criticisms" section. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From bjorn at mork.no Sun Sep 2 10:49:39 2018 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Sun, 02 Sep 2018 12:49:39 +0200 Subject: Service provider story about tracking down TCP RSTs In-Reply-To: (William Herrin's message of "Sun, 2 Sep 2018 06:40:10 -0400") References: <000901d44224$ccdf0210$669d0630$@iname.com> <871sac5i3j.fsf@miraculix.mork.no> Message-ID: <87va7o41j0.fsf@miraculix.mork.no> William Herrin writes: > On Sun, Sep 2, 2018 at 6:06 AM, Bjørn Mork wrote: >> William Herrin writes: >>> https://bill.herrin.us/network/anycasttcp.html >> >> I didn't see a security section in your document. Did you consider the >> side effects of this sequence number abuse? > > Hi Bjørn, > > In the "issues and criticisms" section. I can see the effect on syn cookies being disussed there, but I don't think that covers all concerns wrt more predicatable sequence numbers. See RFC6528, including its references. Bjørn From bill at herrin.us Sun Sep 2 11:45:17 2018 From: bill at herrin.us (William Herrin) Date: Sun, 2 Sep 2018 07:45:17 -0400 Subject: Service provider story about tracking down TCP RSTs In-Reply-To: <87va7o41j0.fsf@miraculix.mork.no> References: <000901d44224$ccdf0210$669d0630$@iname.com> <871sac5i3j.fsf@miraculix.mork.no> <87va7o41j0.fsf@miraculix.mork.no> Message-ID: On Sun, Sep 2, 2018 at 6:49 AM, Bjørn Mork wrote: > William Herrin writes: >> On Sun, Sep 2, 2018 at 6:06 AM, Bjørn Mork wrote: >>> William Herrin writes: >>>> https://bill.herrin.us/network/anycasttcp.html >>> >>> I didn't see a security section in your document. Did you consider the >>> side effects of this sequence number abuse? >> >> In the "issues and criticisms" section. > > I can see the effect on syn cookies being disussed there, but I don't > think that covers all concerns wrt more predicatable sequence numbers. > > See RFC6528, including its references. Thanks Bjørn, I've added several notes in "issues and criticisms" based on that information. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From tarko at lanparty.ee Sun Sep 2 14:43:21 2018 From: tarko at lanparty.ee (Tarko Tikan) Date: Sun, 2 Sep 2018 17:43:21 +0300 Subject: Service provider story about tracking down TCP RSTs In-Reply-To: <5B8BB96F.1040406@jack.fr.eu.org> References: <000901d44224$ccdf0210$669d0630$@iname.com> <5B8BB96F.1040406@jack.fr.eu.org> Message-ID: <272a5c25-435d-a9aa-14d8-d6bd41863f72@lanparty.ee> hey, > But why did the TLS Hello has a TTL lower that the TCP Syn ? > > Do you have any information on that ? Consumer CPEs are typically some BCM reference design where initial TCP handshake is handled by linux kernel and everything following (including NAT) is handled in SOC. I've seen those systems not decrement TTL at all, decrement TTL before checking if packet is destined to itself etc. This case is weird as typically the hardware part is faulty, not the kernel. -- tarko From juergen at jaritsch.at Tue Sep 4 09:32:23 2018 From: juergen at jaritsch.at (=?iso-8859-1?Q?J=FCrgen_Jaritsch?=) Date: Tue, 4 Sep 2018 11:32:23 +0200 Subject: Netflix - wide ranges of wrongly blocked IP ranges Message-ID: <12ba01d44432$360e2fe0$a22a8fa0$@jaritsch.at> Dear list, is anyone else experiencing massive issues with Netflix caused by wrongly blocked IP ranges? Looks like Netflix started to block wide ranges of Colt’s IP assignments (EU & Switzerland). I’m in touch with ~400 affected customers which are no longer able to play any video on the website (“Ooops, something went wrong - Streaming error. Looks like you’re using a Proxy blablabla”). Is someone from Netflix’s NOC on the list? Offnet feedback is welcome - I’m able to provide IPs for verification and I’m able to provide proof for no proxy configuration from Colt J. They do not use any type of CGNAT thanks & best regards JJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmanito at protonmail.com Sun Sep 2 23:07:43 2018 From: tmanito at protonmail.com (Timothy Manito) Date: Sun, 02 Sep 2018 23:07:43 +0000 Subject: Service provider story about tracking down TCP RSTs In-Reply-To: <272a5c25-435d-a9aa-14d8-d6bd41863f72@lanparty.ee> References: <000901d44224$ccdf0210$669d0630$@iname.com> <5B8BB96F.1040406@jack.fr.eu.org> <272a5c25-435d-a9aa-14d8-d6bd41863f72@lanparty.ee> Message-ID: I think it would be a good idea to repost this is reddit.com/r/networking Tim Sent from ProtonMail mobile -------- Original Message -------- On Sep 2, 2018, 10:43 PM, Tarko Tikan wrote: > hey, > >> But why did the TLS Hello has a TTL lower that the TCP Syn ? >> >> Do you have any information on that ? > > Consumer CPEs are typically some BCM reference design where initial TCP > handshake is handled by linux kernel and everything following (including > NAT) is handled in SOC. > > I've seen those systems not decrement TTL at all, decrement TTL before > checking if packet is destined to itself etc. This case is weird as > typically the hardware part is faulty, not the kernel. > > -- > tarko -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at imaginenetworksllc.com Tue Sep 4 15:30:40 2018 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Tue, 4 Sep 2018 11:30:40 -0400 Subject: Netflix - wide ranges of wrongly blocked IP ranges In-Reply-To: <12ba01d44432$360e2fe0$a22a8fa0$@jaritsch.at> References: <12ba01d44432$360e2fe0$a22a8fa0$@jaritsch.at> Message-ID: geosupport at netflix.com are the right folks to help you with this. In the unlikely event that doesn't get you what you need, or if you otherwise need to reach someone at Netflix on the CDN side, please use cdnetops at netflix.com Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Tue, Sep 4, 2018 at 5:32 AM, Jürgen Jaritsch wrote: > Dear list, > > > > is anyone else experiencing massive issues with Netflix caused by wrongly > blocked IP ranges? Looks like Netflix started to block wide ranges of > Colt’s IP assignments (EU & Switzerland). > > > > I’m in touch with ~400 affected customers which are no longer able to play > any video on the website (“Ooops, something went wrong - Streaming error. > Looks like you’re using a Proxy blablabla”). > > > > Is someone from Netflix’s NOC on the list? Offnet feedback is welcome - > I’m able to provide IPs for verification and I’m able to provide proof for > no proxy configuration from Colt J. They do not use any type of CGNAT … > > > > > > thanks & best regards > > JJ > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Tue Sep 4 18:40:46 2018 From: randy at psg.com (Randy Bush) Date: Tue, 04 Sep 2018 11:40:46 -0700 Subject: watch your domain Message-ID: tl;dr: control the domains you use the domain rain.net was on since the early '90s. it used to be the domain of the isp which became verio which became ntt. lots of local portland folk had subdomains, email, ... well, with zero notice, ntt seems to have flogged it off to someone who does not give a damn, and a lot of folk's email and so forth is dead dead dead. packets and smtp falling on the floor. a friend once gave me a tee shirt which says "god helps those who own a majority share." the corollary is that the goddess helps those who own, or otherwise control, the domains on which they rely. randy From bzs at theworld.com Wed Sep 5 03:05:37 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Tue, 4 Sep 2018 23:05:37 -0400 Subject: watch your domain In-Reply-To: References: Message-ID: <23439.18433.980249.48871@gargle.gargle.HOWL> Keep your ip address blocks close, and your domains closer. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From cgrundemann at gmail.com Wed Sep 5 20:15:33 2018 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 5 Sep 2018 16:15:33 -0400 Subject: FYI - IX-Denver Call for Volunteers (3 Board Seats up for Election) Message-ID: >>> FYI <<< IX-Denver will be holding an election at our 2018 members meeting. The purpose of this election will be selecting three Board members for two year terms (2018-2020). To ensure that IX-Denver has the best possible leadership, we are now calling for volunteers who are willing and able to serve our members as Directors. Three Board seats are up for election in 2018, two of which are being vacated: * Mark Calkins - Seeking re-election * Jay Hanke - Not seeking re-election * Ogi Mitev - Not seeking re-election You can view all of the current Board members here: https://ix-denver.org/governance/board-of-directors/ We are seeking volunteers and nominations to fill these three open Board seats. To be considered; please send name, email, and a brief biography to peering at ix-denver.org. # Responsibilities As an all volunteer organization, IX-Denver relies heavily on its Board of Directors. Some of the various tasks performed by current Board members include: * Financial planning and book keeping * Setting strategic direction for the organization based on member input * Providing technical leadership to the organization based on industry best practices * Proposing and conducting configuration changes, upgrades, new installs, etc. * Developing new and existing software tools * Configuring member ports, route server sessions, etc. * Communicating with members directly and via mailing lists * Seeking out new members and partners and bringing them on-board * Evangelizing the use of peering * Website and social media updates * Event planning and execution * Accounts payable and accounts receivable * Leading other volunteers Not all members take on all of these tasks and this is not a comprehensive list. You will need to commit at least 10 hours per month to this position (2-4 hours per week), including monthly online board meetings. Twice a year we meet in person for about a half a day. Folks who live in Colorado and have Internet technology related experience are preferred. In particular this year, we are seeking someone with accounting experience. # Important Dates * 5 September 2018 - Call for Volunteers opens * 20 September 2018 - Call for Volunteers closes * 28 September 2018 - Slate of candidates announced * 18 October 2018 - Members meeting and election * 26 October 2018 - New Board announced This information is also posted here: https://ix-denver.org/governance/2018-election/ Thank you, ~Chris (President, IX-Denver) -- @ChrisGrundemann http://chrisgrundemann.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.kuhnke at gmail.com Thu Sep 6 00:03:25 2018 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Wed, 5 Sep 2018 17:03:25 -0700 Subject: watch your domain In-Reply-To: References: Message-ID: https://medium.com/@gszathmari/hacking-law-firms-abandoned-domain-name-attack-560979e0b774 tl;dr: Expired domain names re-registered by malicious actors after the redemption period are useful for all sorts of mischief. This is a pretty easy to understand read for non-technical management types at customer organizations, who might not understand the importance of how a domain name and its authoritative DNS server records are the single point of failure under a lot of important stuff. On Tue, Sep 4, 2018 at 11:42 AM Randy Bush wrote: > tl;dr: control the domains you use > > the domain rain.net was on since the early '90s. it used to be the > domain of the isp which became verio which became ntt. lots of local > portland folk had subdomains, email, ... > > well, with zero notice, ntt seems to have flogged it off to someone who > does not give a damn, and a lot of folk's email and so forth is dead > dead dead. packets and smtp falling on the floor. > > a friend once gave me a tee shirt which says "god helps those who own a > majority share." the corollary is that the goddess helps those who own, > or otherwise control, the domains on which they rely. > > randy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hibaysal at gmail.com Thu Sep 6 08:40:29 2018 From: hibaysal at gmail.com (H I Baysal) Date: Thu, 6 Sep 2018 10:40:29 +0200 Subject: automatic rtbh trigger using flow data In-Reply-To: <20180831235122.GA92097@lagoon.freebsd.lublin.pl> References: <001c01d4409b$0c4e65c0$24eb3140$@gvtc.com> <5B887E0A.1090809@jmaimon.com> <773bae7e10004d879bce58d216792223@CRA110.am.necel.com> <62e299ab-3b58-515b-81a7-a95101616cba@gmail.com> <20180831235122.GA92097@lagoon.freebsd.lublin.pl> Message-ID: <81f1769c-69d4-88b6-e0d5-6e999d1aa6ac@gmail.com> I also looked at PMACCT, however I have to say that I am way more pleased with the current setup. PMACCT relies on bgp session etc, while you actually get that info from your (s)flow. No need for lookup. And I really didn't like the idea of SQL like DB, I know i could push it to influx. But i thought this could be done way simpler and i think i did exactly that. I store the "raw" info for 7 days, as detailed as possible. then downsample for a week again, a month and a year. And the picture rendering api function of grafana makes it possible for me to do for example /dst AS# or /peer #AS or /as-path AS#  in a chatbot, and grafana actually pushes the graph to telegram in our case, but it could be any bot. So at peering conferences, i can see with 1 message how much traffic we do either to a peer, destination or if traffic passes your AS. I don't see any (pre-made) system beating this :P On 01-09-18 01:51, Paweł Małachowski wrote: > On Fri, Aug 31, 2018 at 11:09:19AM +0200, H I Baysal wrote: > >> My personal view is, as long as you can store your flow info in a >> timeseries database (like influxdb and NOT SQL LIKE!!!!!!!) you can do >> whatever you want with the (raw) data. And create custom triggers for >> different calculations. > For one of our customers I've deployed good old pmacct + MySQL > (using memory engine) backend for DDoS detection purposes. > It has some drawbacks (e.g. one has to frequently delete old > records to keep tables fit and fast) but it allows asking complex > SQL queries against these short term data (e.g. different detection > logic per subnets) or precompute with triggers. > >> Flows are on the fly and are coming in constantly, you could have a >> calculation like group by srcip and whatever protocol you want or just >> srcip, > Beware of high cardinality issues when facing random src IP floods. > > BTW, once again pmacct (with some glue) is nice for feeding flow > data into time series database. It can pre aggregate and pre filter > low volume flows to reduce storage requirements. > > From michael at wi-fiber.io Thu Sep 6 14:48:38 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Thu, 6 Sep 2018 08:48:38 -0600 Subject: Fubo.tv Another erroneous Geoblock Message-ID: anyone know who to contact at fubo.tv? Getting an improper geoblock for our location -------------- next part -------------- An HTML attachment was scrubbed... URL: From benno at NLnetLabs.nl Fri Sep 7 12:47:31 2018 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Fri, 7 Sep 2018 14:47:31 +0200 Subject: Last call for presentations and Draft programme for RIPE 77 Message-ID: <0770d70e-4171-0f35-064c-5b4d7764a788@NLnetLabs.nl> Colleagues, A list of currently accepted RIPE 77 presentations is now published at: https://ripe77.ripe.net/programme/meeting-plan/plenary/ There are still plenary, BoF, tutorial and workshop slots remaining for the final RIPE 77 programme and RIPE Programme Committee will accept new proposals until *21 September 2018*. This is our last call for you to submit your proposals. You can find the CFP for RIPE 77 below or at https://ripe77.ripe.net/submit-topic/cfp/, for your proposals for plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings, see the "Speakers" paragraph in CFP for more information. Kind regards, Benno Overeinder RIPE PC Chair https://ripe77.ripe.net/ripe-pc/ -------------------->>><<<-------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. *RIPE 77 will take place from 15-19 October in Amsterdam, The Netherlands* The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 77. See the full descriptions of the different presentation formats: https://ripe77.ripe.net/submit-topic/presentation-formats/ Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than *21 September 2018*. Proposals submitted after this date will be considered depending on the slots still available in the programme. The PC is looking for presentations covering the topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange - Connected Things (aka. Internet of Things - IoT) ---- Speakers ---- Presenters, RIPE Working Group Chairs and the RIPE Programme Committee are required to cover their own costs to attend a RIPE Meeting (meeting ticket, travel and accommodation). We have various ticket options available depending on your needs. In extraordinary circumstances, the RIPE Chair can waive the meeting fee for presenters. These requests are dealt with on a case-by-case basis via pc at ripe.net. Also note that, on an individual basis, participants can apply for a RIPE Fellowship or RACI to develop their professional or academic career. For more information, please visit: https://www.ripe.net/participate/ripe/ripe-fellowship https://www.ripe.net/participate/ripe/raci ---- Submissions ---- Presenters should be clear on whether they wish to submit a presentation for a plenary or working group (WG) session. At present, most working groups will solicit policy proposals, discussion points or other content directly via their mailing lists. If you’re not sure what kind of session you should be presenting at, please visit: https://ripe77.ripe.net/plenary-or-wg/ RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and should not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour (during evening sessions) - Lightning talks: 10 minutes in total for both the presentation and any discussion The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe77.ripe.net/submit-topic/ - Lightning talks should also be submitted using the meeting submission system (https://ripe77.ripe.net/submit-topic/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice, in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. ---- Diversity and Inclusion - On-Site Childcare and the RIPE Meeting Code of Conduct ---- Did you know that RIPE Meetings now have on-site childcare? You can reserve a spot for your child (age 6 months – 10 years) during the registration process for the meeting. Registrations for RIPE 77 will open mid-July. Childcare places are limited, so please be quick to reserve a spot for your child! Read about the experiences of our next generation of engineers at: https://labs.ripe.net/Members/agowland/ripe-meeting-diversity-efforts-on-site-childcare-at-ripe-76 Ensuring that RIPE Meeting values are upheld and that attendees experience a professional, respectful and safe meeting is a priority. Please do read the RIPE Meeting Code of Conduct: https://www.ripe.net/participate/meetings/ripe-meetings/ripe-meeting-code-of-conduct --- If you have any questions or requests concerning content submissions, please email pc at ripe.net. From mehmet at akcin.net Fri Sep 7 12:51:11 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Fri, 7 Sep 2018 06:51:11 -0600 Subject: Vultr contact Message-ID: Hello, I have been looking for a contact in Vultr for awhile now. Can anyone help me contact with them? (i need help beyond their sales/support channels) mehmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From niels=nanog at bakker.net Fri Sep 7 13:03:59 2018 From: niels=nanog at bakker.net (Niels Bakker) Date: Fri, 7 Sep 2018 15:03:59 +0200 Subject: Vultr contact In-Reply-To: References: Message-ID: <20180907130359.GE9970@jima.tpb.net> * mehmet at akcin.net (Mehmet Akcin) [Fri 07 Sep 2018, 14:51 CEST]: >I have been looking for a contact in Vultr for awhile now. Can >anyone help me contact with them? > >(i need help beyond their sales/support channels) You posted the same thing on 29 August. I suggest you look for replies to that email. -- Niels. From mehmet at akcin.net Fri Sep 7 13:06:51 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Fri, 7 Sep 2018 07:06:51 -0600 Subject: Vultr contact In-Reply-To: <20180907130359.GE9970@jima.tpb.net> References: <20180907130359.GE9970@jima.tpb.net> Message-ID: I got no response really. people were more like sharing their experience. i guess there isn't anyone. On Fri, Sep 7, 2018 at 7:03 AM Niels Bakker wrote: > * mehmet at akcin.net (Mehmet Akcin) [Fri 07 Sep 2018, 14:51 CEST]: > >I have been looking for a contact in Vultr for awhile now. Can > >anyone help me contact with them? > > > >(i need help beyond their sales/support channels) > > You posted the same thing on 29 August. I suggest you look for > replies to that email. > > > -- Niels. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magicsata at gmail.com Fri Sep 7 13:27:05 2018 From: magicsata at gmail.com (Alistair Mackenzie) Date: Fri, 7 Sep 2018 14:27:05 +0100 Subject: Vultr contact In-Reply-To: References: <20180907130359.GE9970@jima.tpb.net> Message-ID: Have you tried choopa? They own and/or operate vultr. On Fri, Sep 7, 2018 at 2:09 PM Mehmet Akcin wrote: > I got no response really. people were more like sharing their experience. > i guess there isn't anyone. > > On Fri, Sep 7, 2018 at 7:03 AM Niels Bakker > wrote: > >> * mehmet at akcin.net (Mehmet Akcin) [Fri 07 Sep 2018, 14:51 CEST]: >> >I have been looking for a contact in Vultr for awhile now. Can >> >anyone help me contact with them? >> > >> >(i need help beyond their sales/support channels) >> >> You posted the same thing on 29 August. I suggest you look for >> replies to that email. >> >> >> -- Niels. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From agemberjacobson at colgate.edu Fri Sep 7 13:51:34 2018 From: agemberjacobson at colgate.edu (Aaron Gember-Jacobson) Date: Fri, 7 Sep 2018 09:51:34 -0400 Subject: Study on configuration change practices Message-ID: We are a team of networking researchers at the University of Wisconsin-Madison and Colgate University investigating methods for automatically synthesizing router configurations from high-level requirements (or intents). To guide our research, we seek to better understand the configuration change practices used in production networks. We would appreciate if you could take 3 minutes to complete our brief, anonymous survey: https://colgate.co1.qualtrics.com/jfe/form/SV_3ee26xayy70jP3D To learn more about our research, visit http://aaron.gember-jacobson.com/research/repair Thanks, Aaron Gember-Jacobson *Assistant Professor of Computer Science* *Colgate University* -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron1 at gvtc.com Fri Sep 7 15:53:24 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 7 Sep 2018 10:53:24 -0500 Subject: Study on configuration change practices In-Reply-To: References: Message-ID: <001b01d446c2$e9169cc0$bb43d640$@gvtc.com> Hi Aaron, interesting …making routers do what you intend…hmmm… Sounds like SDN J …how does what you are doing differ from the intent-based-controller driven sdn concepts that I hear so much about these days. BTW, I did the survey. - Aaron From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Aaron Gember-Jacobson Sent: Friday, September 7, 2018 8:52 AM To: nanog at nanog.org Subject: Study on configuration change practices We are a team of networking researchers at the University of Wisconsin-Madison and Colgate University investigating methods for automatically synthesizing router configurations from high-level requirements (or intents). To guide our research, we seek to better understand the configuration change practices used in production networks. We would appreciate if you could take 3 minutes to complete our brief, anonymous survey: https://colgate.co1.qualtrics.com/jfe/form/SV_3ee26xayy70jP3D To learn more about our research, visit http://aaron.gember-jacobson.com/research/repair Thanks, Aaron Gember-Jacobson Assistant Professor of Computer Science Colgate University -------------- next part -------------- An HTML attachment was scrubbed... URL: From cscora at apnic.net Fri Sep 7 18:03:10 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 8 Sep 2018 04:03:10 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180907180310.EF248C450F@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 08 Sep, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 714282 Prefixes after maximum aggregation (per Origin AS): 274250 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 343136 Total ASes present in the Internet Routing Table: 61743 Prefixes per ASN: 11.57 Origin-only ASes present in the Internet Routing Table: 53330 Origin ASes announcing only one prefix: 23274 Transit ASes present in the Internet Routing Table: 8413 Transit-only ASes present in the Internet Routing Table: 260 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 34 Max AS path prepend of ASN ( 30873) 32 Prefixes from unregistered ASNs in the Routing Table: 70 Number of instances of unregistered ASNs: 70 Number of 32-bit ASNs allocated by the RIRs: 23997 Number of 32-bit ASNs visible in the Routing Table: 19338 Prefixes from 32-bit ASNs in the Routing Table: 80928 Number of bogon 32-bit ASNs visible in the Routing Table: 30 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 309 Number of addresses announced to Internet: 2854496324 Equivalent to 170 /8s, 36 /16s and 40 /24s Percentage of available address space announced: 77.1 Percentage of allocated address space announced: 77.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.0 Total number of prefixes smaller than registry allocations: 238728 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 194899 Total APNIC prefixes after maximum aggregation: 55458 APNIC Deaggregation factor: 3.51 Prefixes being announced from the APNIC address blocks: 193038 Unique aggregates announced from the APNIC address blocks: 79417 APNIC Region origin ASes present in the Internet Routing Table: 9064 APNIC Prefixes per ASN: 21.30 APNIC Region origin ASes announcing only one prefix: 2553 APNIC Region transit ASes present in the Internet Routing Table: 1359 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 31 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4025 Number of APNIC addresses announced to Internet: 767575043 Equivalent to 45 /8s, 192 /16s and 68 /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: 212189 Total ARIN prefixes after maximum aggregation: 100504 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 211894 Unique aggregates announced from the ARIN address blocks: 100633 ARIN Region origin ASes present in the Internet Routing Table: 18243 ARIN Prefixes per ASN: 11.62 ARIN Region origin ASes announcing only one prefix: 6778 ARIN Region transit ASes present in the Internet Routing Table: 1805 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2425 Number of ARIN addresses announced to Internet: 1100193184 Equivalent to 65 /8s, 147 /16s and 157 /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: 195459 Total RIPE prefixes after maximum aggregation: 93307 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 191769 Unique aggregates announced from the RIPE address blocks: 113734 RIPE Region origin ASes present in the Internet Routing Table: 25451 RIPE Prefixes per ASN: 7.53 RIPE Region origin ASes announcing only one prefix: 11468 RIPE Region transit ASes present in the Internet Routing Table: 3511 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7369 Number of RIPE addresses announced to Internet: 714094464 Equivalent to 42 /8s, 144 /16s and 55 /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: 92235 Total LACNIC prefixes after maximum aggregation: 20783 LACNIC Deaggregation factor: 4.44 Prefixes being announced from the LACNIC address blocks: 93668 Unique aggregates announced from the LACNIC address blocks: 40918 LACNIC Region origin ASes present in the Internet Routing Table: 7510 LACNIC Prefixes per ASN: 12.47 LACNIC Region origin ASes announcing only one prefix: 2075 LACNIC Region transit ASes present in the Internet Routing Table: 1412 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 34 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5055 Number of LACNIC addresses announced to Internet: 172160544 Equivalent to 10 /8s, 66 /16s and 246 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 19429 Total AfriNIC prefixes after maximum aggregation: 4138 AfriNIC Deaggregation factor: 4.70 Prefixes being announced from the AfriNIC address blocks: 23604 Unique aggregates announced from the AfriNIC address blocks: 8169 AfriNIC Region origin ASes present in the Internet Routing Table: 1189 AfriNIC Prefixes per ASN: 19.85 AfriNIC Region origin ASes announcing only one prefix: 400 AfriNIC Region transit ASes present in the Internet Routing Table: 238 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 26 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 464 Number of AfriNIC addresses announced to Internet: 100022272 Equivalent to 5 /8s, 246 /16s and 56 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 4686 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4426 478 471 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 2993 1154 90 VIETEL-AS-AP Viettel Group, VN 4766 2823 11135 771 KIXS-AS-KR Korea Telecom, KR 9829 2811 1495 540 BSNL-NIB National Internet Backbone, IN 45899 2719 1650 158 VNPT-AS-VN VNPT Corp, VN 9394 2630 4907 32 CTTNET China TieTong Telecommunications 9808 2263 8699 26 CMNET-GD Guangdong Mobile Communication 17974 2258 962 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4755 2122 417 204 TATACOMM-AS TATA Communications formerl Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3472 1324 84 SHAW - Shaw Communications Inc., CA 11492 3339 238 497 CABLEONE - CABLE ONE, INC., US 22773 3227 2970 149 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2283 4874 785 AMAZON-02 - Amazon.com, Inc., US 18566 2166 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2151 2699 508 CHARTER-NET-HKY-NC - Charter Communicat 209 2039 5085 603 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 2037 346 138 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 16625 2010 1054 1477 AKAMAI-AS - Akamai Technologies, Inc., 7018 1726 19679 1261 ATT-INTERNET4 - AT&T Services, Inc., US 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 4771 1613 125 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3065 378 44 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2573 622 1911 AKAMAI-ASN1, US 12389 2042 1897 734 ROSTELECOM-AS, RU 34984 2028 336 510 TELLCOM-AS, TR 9121 1852 1692 19 TTNET, TR 13188 1604 100 43 TRIOLAN, UA 6849 1241 355 21 UKRTELNET, UA 8402 1218 544 14 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 5216 3352 606 Uninet S.A. de C.V., MX 10620 3394 516 588 Telmex Colombia S.A., CO 11830 2651 369 78 Instituto Costarricense de Electricidad 6503 1671 444 65 Axtel, S.A.B. de C.V., MX 7303 1430 953 206 Telecom Argentina S.A., AR 28573 1094 2231 192 CLARO S.A., BR 3816 1022 510 116 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 932 128 70 Alestra, S. de R.L. de C.V., MX 6147 929 377 31 Telefonica del Peru S.A.A., PE 18881 916 1082 27 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1195 396 48 LINKdotNET-AS, EG 37611 900 107 9 Afrihost, ZA 36903 778 391 137 MT-MPLS, MA 36992 746 1411 41 ETISALAT-MISR, EG 24835 641 818 18 RAYA-AS, EG 8452 597 1728 14 TE-AS TE-AS, EG 37492 474 470 57 ORANGE-, TN 29571 464 70 11 ORANGE-COTE-IVOIRE, CI 37342 386 32 1 MOVITEL, MZ 23889 375 231 15 MauritiusTelecom, MU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5216 3352 606 Uninet S.A. de C.V., MX 12479 4771 1613 125 UNI2-AS, ES 4538 4686 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4426 478 471 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 6327 3472 1324 84 SHAW - Shaw Communications Inc., CA 10620 3394 516 588 Telmex Colombia S.A., CO 11492 3339 238 497 CABLEONE - CABLE ONE, INC., US 22773 3227 2970 149 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 8551 3065 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 4771 4646 UNI2-AS, ES 4538 4686 4612 ERX-CERNET-BKB China Education and Research Net 7545 4426 3955 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3472 3388 SHAW - Shaw Communications Inc., CA 22773 3227 3078 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3065 3021 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 2993 2903 VIETEL-AS-AP Viettel Group, VN 11492 3339 2842 CABLEONE - CABLE ONE, INC., US 10620 3394 2806 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 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 4200003000 PRIVATE 47.89.98.0/24 45102 CNNIC-ALIBABA-CN-NET-AP Alibab 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 64121 UNALLOCATED 98.159.9.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64121 UNALLOCATED 98.159.12.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64140 UNALLOCATED 98.159.14.0/24 64121 UNKNOWN 64544 PRIVATE 103.55.56.0/24 133831 IDNIC-ID Indonesia Network Inf Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.179.2.0/24 6939 HURRICANE - Hurricane Electric LLC, US 27.100.7.0/24 56096 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 45.121.32.0/22 134356 UNKNOWN 45.124.164.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU 45.252.236.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:14 /9:11 /10:36 /11:99 /12:290 /13:565 /14:1096 /15:1885 /16:13335 /17:7923 /18:13795 /19:25364 /20:39518 /21:45692 /22:88657 /23:72277 /24:401525 /25:819 /26:616 /27:633 /28:35 /29:20 /30:19 /31:4 /32:54 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 3521 4771 UNI2-AS, ES 6327 3260 3472 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2661 3339 CABLEONE - CABLE ONE, INC., US 8551 2527 3065 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2494 3227 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2060 2166 MEGAPATH5-US - MegaPath Corporation, US 11830 2001 2651 Instituto Costarricense de Electricidad y Telec 30036 1785 2037 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1545 3394 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1596 2:833 4:18 5:2825 6:44 7:1 8:1129 12:1870 13:209 14:1806 15:32 16:3 17:194 18:54 20:51 23:2460 24:2311 25:2 27:2483 31:1984 32:88 35:29 36:530 37:2822 38:1496 39:261 40:116 41:3198 42:706 43:1945 44:112 45:5463 46:3133 47:209 49:1354 50:1055 51:318 52:1087 54:368 55:1 56:8 57:38 58:1632 59:993 60:408 61:2112 62:1896 63:1800 64:5046 65:2218 66:4693 67:2660 68:1153 69:3349 70:1156 71:576 72:2220 74:2734 75:420 76:465 77:1648 78:1712 79:2240 80:1565 81:1398 82:1064 83:785 84:1034 85:2027 86:563 87:1417 88:914 89:2339 90:210 91:6434 92:1250 93:2377 94:2460 95:2966 96:933 97:355 98:926 99:138 100:86 101:1188 102:203 103:18597 104:3522 105:216 106:771 107:1776 108:706 109:3323 110:1644 111:1795 112:1345 113:1302 114:1138 115:1668 116:1657 117:1778 118:2208 119:1660 120:1032 121:1042 122:2422 123:1659 124:1427 125:1935 128:1125 129:679 130:492 131:1631 132:734 133:191 134:1029 135:235 136:507 137:655 138:1909 139:681 140:485 141:747 142:844 143:1025 144:816 145:480 146:1245 147:733 148:1654 149:773 150:762 151:1101 152:833 153:323 154:1627 155:803 156:1443 157:802 158:660 159:1855 160:1365 161:823 162:2672 163:605 164:1088 165:1552 166:455 167:1210 168:3139 169:829 170:3880 171:491 172:992 173:2099 174:977 175:803 176:2059 177:3977 178:2515 179:1259 180:2179 181:2432 182:2580 183:1250 184:1056 185:13996 186:3540 187:2506 188:2879 189:2033 190:8197 191:1349 192:9831 193:6141 194:5015 195:3994 196:2699 197:1608 198:5589 199:5940 200:7321 201:4975 202:10293 203:10291 204:4584 205:2905 206:3222 207:3195 208:3927 209:4082 210:3891 211:1999 212:3044 213:2831 214:1047 215:55 216:5998 217:2135 218:863 219:566 220:1806 221:999 222:990 223:1395 End of report From colton.conor at gmail.com Sat Sep 8 16:59:12 2018 From: colton.conor at gmail.com (Colton Conor) Date: Sat, 8 Sep 2018 11:59:12 -0500 Subject: uCPE or SD-WAN Devices with LTE Support Message-ID: We have been using cradlepoint routers, but we want a device that has the functionality of a cradlepoint with the ability to run own own applications naively on Linux. cradlepoint does not allow you to run your own apps on the device itself eventhogh the newer cradlepoint has a quad core processor. Does anyone have recommendations for a UCPE or SD-WAN device that: cost about what a Cradlepoint cost ($500 to $750) have built in LTE (or supports a M.2 LTE card) has at least one Ethernet port has remote management, and can load your own application onto? We could probably build out own with a marker board of some sort and a Sierra Wireless LTE card, but what linux operating system would be best for this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From agemberjacobson at colgate.edu Sat Sep 8 20:42:02 2018 From: agemberjacobson at colgate.edu (Aaron Gember-Jacobson) Date: Sat, 8 Sep 2018 16:42:02 -0400 Subject: Study on configuration change practices In-Reply-To: <001b01d446c2$e9169cc0$bb43d640$@gvtc.com> References: <001b01d446c2$e9169cc0$bb43d640$@gvtc.com> Message-ID: The key distinction of our research is that it focuses on networks running traditional distributed routing protocols. In an SDN you have significant flexibility over how you decide to route/filter traffic, whereas in a traditional network you have to satisfy intents using the capabilities of existing routing protocols. Obviously SDN's flexibility is what makes it attractive, but there is also (significant) overhead to (partially) switch to this architectures. We recognize that traditional routing protocols still far outstrip SDN in terms of deployment, so there is a real need for intent-driven frameworks that work with traditional routing protocols. We are not alone in building intent-driven frameworks for traditional routing protocols. Other research (e.g., https://netcomplete.ethz.ch and https://github.com/rabeckett/propane) has also taken an intent-driven approach for traditional routing protocols. What differentiates our work is a focus on _updating_ existing configurations rather than generating new configurations from scratch each time the intents change. Aaron P.S. Thanks for taking the survey! On Fri, Sep 7, 2018 at 11:53 AM Aaron Gould wrote: > Hi Aaron, interesting …making routers do what you intend…hmmm… Sounds > like SDN J …how does what you are doing differ from the > intent-based-controller driven sdn concepts that I hear so much about these > days. > > > > BTW, I did the survey. > > > > - Aaron > > > > *From:* NANOG [mailto:nanog-bounces at nanog.org] *On Behalf Of *Aaron > Gember-Jacobson > *Sent:* Friday, September 7, 2018 8:52 AM > *To:* nanog at nanog.org > *Subject:* Study on configuration change practices > > > > We are a team of networking researchers at the University of > Wisconsin-Madison and Colgate University investigating methods for > automatically synthesizing router configurations from high-level > requirements (or intents). To guide our research, we seek to better > understand the configuration change practices used in production networks. > > We would appreciate if you could take 3 minutes to complete our brief, anonymous > survey: https://colgate.co1.qualtrics.com/jfe/form/SV_3ee26xayy70jP3D > > To learn more about our research, visit > http://aaron.gember-jacobson.com/research/repair > > Thanks, > Aaron Gember-Jacobson > > *Assistant Professor of Computer Science* > > *Colgate University* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbothe at me.com Sat Sep 8 23:25:36 2018 From: jbothe at me.com (JASON BOTHE) Date: Sat, 08 Sep 2018 20:25:36 -0300 Subject: Bell Canada IP transit - NID required? Message-ID: <8FE29084-F45D-473B-9828-5B66083B544D@me.com> All, Just curious if anyone uses Bell Canada for IP transit in a colo environment and whether or not you were able to obtain a traditional cross-connect without having Bell place a managed CPE device in your cage. I can’t seem to find anyone intelligent enough to tell my any different other than “it’s never been done before” and “we need remote testing capabilities.” J~ From edugas at unknowndevice.ca Sun Sep 9 02:02:34 2018 From: edugas at unknowndevice.ca (Eric Dugas) Date: Sat, 8 Sep 2018 22:02:34 -0400 Subject: Bell Canada IP transit - NID required? In-Reply-To: <8FE29084-F45D-473B-9828-5B66083B544D@me.com> References: <8FE29084-F45D-473B-9828-5B66083B544D@me.com> Message-ID: I've requested many times 1G/10G EI circuits without CPEs and even had Settlement based peering from AS577 delivered on an EVC on a CPE-less ENNI so they definitely be flexible. This was with Bell wholesale thought. If you deal with retail, your experience may vary... On Sat, Sep 8, 2018, 19:25 JASON BOTHE via NANOG wrote: > > All, > > Just curious if anyone uses Bell Canada for IP transit in a colo > environment and whether or not you were able to obtain a traditional > cross-connect without having Bell place a managed CPE device in your cage. > I can’t seem to find anyone intelligent enough to tell my any different > other than “it’s never been done before” and “we need remote testing > capabilities.” > > J~ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clayton at MNSi.Net Sun Sep 9 15:04:42 2018 From: clayton at MNSi.Net (Clayton Zekelman) Date: Sun, 09 Sep 2018 11:04:42 -0400 Subject: Bell Canada IP transit - NID required? In-Reply-To: <8FE29084-F45D-473B-9828-5B66083B544D@me.com> References: <8FE29084-F45D-473B-9828-5B66083B544D@me.com> Message-ID: <1536505483_552546@surgemail.mnsi.net> We used to have a GigE transit port terminated on CO connecting links inside one of their COs long ago. No CPE. They may have changed their policy since then. At 07:25 PM 08/09/2018, JASON BOTHE via NANOG wrote: >All, > >Just curious if anyone uses Bell Canada for IP >transit in a colo environment and whether or not >you were able to obtain a traditional >cross-connect without having Bell place a >managed CPE device in your cage. I can’t seem >to find anyone intelligent enough to tell my any >different other than “it’s never been done >before” and “we need remote testing capabilities.” > >J~ -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From mehmet at akcin.net Mon Sep 10 02:55:04 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Sun, 9 Sep 2018 19:55:04 -0700 Subject: Vultr contact In-Reply-To: References: <20180907130359.GE9970@jima.tpb.net> Message-ID: It is not related to BGP setup. It's related to network quality and discussion on how to fix it. Their support is awesome but problems don't get resolved in network side. On Sun, Sep 9, 2018 at 7:51 AM Hien Phan wrote: > Hello mehmet, > > Which type of information you need with them? I worked with them in the > past about bgp peering setup. They're usually reply in 12 hours or less. > > Hien. > > On Fri, Sep 7, 2018 at 8:27 PM, Alistair Mackenzie > wrote: > >> Have you tried choopa? They own and/or operate vultr. >> >> On Fri, Sep 7, 2018 at 2:09 PM Mehmet Akcin wrote: >> >>> I got no response really. people were more like sharing their >>> experience. i guess there isn't anyone. >>> >>> On Fri, Sep 7, 2018 at 7:03 AM Niels Bakker >>> wrote: >>> >>>> * mehmet at akcin.net (Mehmet Akcin) [Fri 07 Sep 2018, 14:51 CEST]: >>>> >I have been looking for a contact in Vultr for awhile now. Can >>>> >anyone help me contact with them? >>>> > >>>> >(i need help beyond their sales/support channels) >>>> >>>> You posted the same thing on 29 August. I suggest you look for >>>> replies to that email. >>>> >>>> >>>> -- Niels. >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Mon Sep 10 13:32:00 2018 From: beecher at beecher.cc (Tom Beecher) Date: Mon, 10 Sep 2018 09:32:00 -0400 Subject: Service provider story about tracking down TCP RSTs In-Reply-To: <000901d44224$ccdf0210$669d0630$@iname.com> References: <000901d44224$ccdf0210$669d0630$@iname.com> Message-ID: Can you share the Arista model and EOS version of the devices you installed that TTL hashing was enabled by default? On Sat, Sep 1, 2018 at 2:51 PM, wrote: > I want to share a little bit of our journey in tracking down the TCP RSTs > that impacted some of our customers for almost ten weeks. > > > > Almost immediately after we turned up two new Arista border routers in > late July we started receiving a trickle of complaints from customers > regarding their inability to access certain websites (mostly B2B). All the > packet captures showed the standard TCP SYN/SYN-ACK pair, then a TCP RST > from the website after the client sent a TLS/SSL Client Hello. As the > reports continued to come in, we built a Google Doc to keep track and it > became clear that most of the sites were hosted by Incapsula/Imperva, but > there were also a few by Sucuri and Fastly. Knowing that Incapsula provides > DoS protection, we attempted to work with them (providing websites, > source/destination IPs, traceroutes, and packet captures) to find out why > their hosts were issuing our customers a TCP RST, but we made little > progress. We moved some of the affected customers to different IP addresses > but that didn’t resolve the issue. We also asked our customer to work with > the website to see if they would be willing to open a ticket with > Incapsula. In the meantime, customers were getting frustrated! They > couldn’t visit Incapsula-hosted healthcare websites, financial firms, > product dealers, etc. Over the weeks, a few of those customers > purchased/borrowed different routers and some of those didn’t have website > issues anymore. And more than a few of them discovered that the websites > worked fine from home or their mobile phone/hotspot, but not from their > Internet connection with us. You can guess where they were applying > pressure! That said, we didn’t know why a small handful of companies, known > for DoS protection, were issuing TCP RSTs to just some of our customers. > > > > Earlier this week we received four or five more websites from yet another > affected customer, but most of those were with Fastly. By this time, we had > been able to replicate the issue in our lab. Feeling desperate to make some > tangible progress on this issue, I reached out to the Fastly NOC. In less > than 12 hours they provided some helpful feedback, pointing out that a > single traceroute to a Fastly site was hitting two of their POPs (they use > anycast) and because they don’t sync state between POPs the second POP > would naturally issue a TCP RST (sidebar: fascinating blog article on > Fastly’s infrastructure here: https://www.fastly.com/blog/ > building-and-scaling-fastly-network-part-2-balancing-requests). In > subsequent email exchanges, the Fastly NOC suggested that it appeared that > we were “spraying flows” (that is, packets related to single client session > were egressing our network via different paths). Because Fastly is also > present with us at an IX (though they weren’t advertising their anycast IPs > at the time), they suggested that we look at how our traffic egresses our > network (IX versus transit) and our routers’ outbound > load-balancing/hashing schemes. > > > > The IX turned up to be a red herring, so I turned my attention to our > transit. Each of our border routers has two BGP sessions over two circuits > to transit provider POP A and two BGP sessions over two circuits to transit > provider POP B, for a total of four BGP sessions per border router, a total > of eight BGP sessions altogether. Starting with our core router, I > confirmed that its ECMP hashing was consistent such that Fastly-bound > traffic always went to border router 1 or border router 2. Then I looked at > the ECMP hashing scheme on our border routers and noticed something unique > – by default Arista also uses TTL: > > > > IPv4 hash fields: > > Source IPv4 Address is ON > > Protocol is ON > > Time-To-Live is ON > > Destination IPv4 Address is ON > > > > Since the source and destination IPs and protocol weren’t changing, > perhaps the TTL was not consistent? I opened the first packet trace in > Wireshark and jackpot – the TTL value was 128 on the SYN but 127 on the > TLS/SSL Client Hello. I adjusted the Arista’s load-balancing profile not to > use TTL and immediately my MTR in the background changed and all the sites > on the lab machine that couldn’t load before … were now loading. > > > > Fastly also pointed me to another article written by Joel Jaeggli ( > https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/) that > discusses IPv6 flow labels – we removed that from the border routers’ IPv6 > hash fields, too. > > > > I reviewed the packet traces today and noticed that TTL values remained > consistent at 128 **behind** the router CPE. In packet captures on the > WAN interface of the router CPE I see that the SYN remains at 128, but the > TLS/Client Hello is properly decremented to 127. So, it appears that some > router CPE (and there were a variety of makes and models) are doing > something special to certain packets and not decrementing the TTL. > > This explains why: > > - our customers had issues with all their devices behind their router > CPE > - the issue remained regardless of what public IP address their router > CPE obtained via DHCP or was assigned > - some customers who changed their router CPE didn’t have the issue > anymore – they got lucky with a router that doesn’t adjust/reset the TTL > - why customers who used our managed Wi-Fi router did not see the > issue, because that model doesn’t apparently manipulate the TTL, at least > not in an inconsistent way. > > > > Lesson learned: review a device’s hashing mechanism before going into > production. > > > > For those interested, I have links to the packet traces below my > signature, showing the inconsistent TTL values. > > > > Thanks again to the fantastic group of folk at the Fastly NOC who so ably > pointed us in the right direction! > > > > Frank > > > > https://www.premieronline.net/~fbulk/example1.pcapng > > https://www.premieronline.net/~fbulk/example2.pcapng > > https://www.premieronline.net/~fbulk/example3.pcapng > -------------- next part -------------- An HTML attachment was scrubbed... URL: From j0hn.hurl3y at gmail.com Sun Sep 9 01:22:35 2018 From: j0hn.hurl3y at gmail.com (John Hurley) Date: Sat, 8 Sep 2018 21:22:35 -0400 Subject: Bell Canada IP transit - NID required? In-Reply-To: <8FE29084-F45D-473B-9828-5B66083B544D@me.com> References: <8FE29084-F45D-473B-9828-5B66083B544D@me.com> Message-ID: I'm fairly certain I was told if I was in bell Colo they would be passing me Ethernet without a CPE/nid. I'm also pretty sure they said they normally do that where possible in Colo. But I could be wrong. My last discussions were with wholesale. --john On Sat, Sep 8, 2018, 7:26 PM JASON BOTHE via NANOG wrote: > > All, > > Just curious if anyone uses Bell Canada for IP transit in a colo > environment and whether or not you were able to obtain a traditional > cross-connect without having Bell place a managed CPE device in your cage. > I can’t seem to find anyone intelligent enough to tell my any different > other than “it’s never been done before” and “we need remote testing > capabilities.” > > J~ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbilyk at gmail.com Sun Sep 9 02:29:59 2018 From: jbilyk at gmail.com (Jeff Bilyk) Date: Sat, 8 Sep 2018 22:29:59 -0400 Subject: Bell Canada IP transit - NID required? In-Reply-To: References: <8FE29084-F45D-473B-9828-5B66083B544D@me.com> Message-ID: +1 to using their wholesale platform to accomplish this, either via an account rep or WSS portal. On Sat, Sep 8, 2018, 10:04 PM Eric Dugas wrote: > I've requested many times 1G/10G EI circuits without CPEs and even had > Settlement based peering from AS577 delivered on an EVC on a CPE-less ENNI > so they definitely be flexible. > > This was with Bell wholesale thought. If you deal with retail, your > experience may vary... > > On Sat, Sep 8, 2018, 19:25 JASON BOTHE via NANOG wrote: > >> >> All, >> >> Just curious if anyone uses Bell Canada for IP transit in a colo >> environment and whether or not you were able to obtain a traditional >> cross-connect without having Bell place a managed CPE device in your cage. >> I can’t seem to find anyone intelligent enough to tell my any different >> other than “it’s never been done before” and “we need remote testing >> capabilities.” >> >> J~ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phanquochien at gmail.com Sun Sep 9 14:51:26 2018 From: phanquochien at gmail.com (Hien Phan) Date: Sun, 9 Sep 2018 21:51:26 +0700 Subject: Vultr contact In-Reply-To: References: <20180907130359.GE9970@jima.tpb.net> Message-ID: Hello mehmet, Which type of information you need with them? I worked with them in the past about bgp peering setup. They're usually reply in 12 hours or less. Hien. On Fri, Sep 7, 2018 at 8:27 PM, Alistair Mackenzie wrote: > Have you tried choopa? They own and/or operate vultr. > > On Fri, Sep 7, 2018 at 2:09 PM Mehmet Akcin wrote: > >> I got no response really. people were more like sharing their experience. >> i guess there isn't anyone. >> >> On Fri, Sep 7, 2018 at 7:03 AM Niels Bakker >> wrote: >> >>> * mehmet at akcin.net (Mehmet Akcin) [Fri 07 Sep 2018, 14:51 CEST]: >>> >I have been looking for a contact in Vultr for awhile now. Can >>> >anyone help me contact with them? >>> > >>> >(i need help beyond their sales/support channels) >>> >>> You posted the same thing on 29 August. I suggest you look for >>> replies to that email. >>> >>> >>> -- Niels. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From spoofer-info at caida.org Sat Sep 8 17:00:03 2018 From: spoofer-info at caida.org (CAIDA Spoofer Project) Date: Sat, 8 Sep 2018 10:00:03 -0700 Subject: Spoofer Report for NANOG for Aug 2018 Message-ID: <201809081700.w88H03bi073763@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 Aug 2018: ASN Name Fixed-By 33651 CMCS 2018-08-15 2152 CSUNET-NW 2018-08-20 54417 STIMULUS-TECHNOLOGIES 2018-08-22 21949 BEANFIELD 2018-08-29 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Aug 2018: ASN Name First-Spoofed Last-Spoofed 3356 LEVEL3 2016-03-06 2018-08-13 577 BACOM 2016-03-09 2018-08-27 7922 COMCAST-7922 2016-06-04 2018-08-28 20115 CHARTER-NET-HKY-NC 2016-06-09 2018-08-23 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2018-08-29 6128 CABLE-NET-1 2016-09-03 2018-08-11 11232 MIDCO-NET 2016-09-22 2018-08-11 20412 CLARITY-TELECOM 2016-09-30 2018-08-28 6181 FUSE-NET 2016-10-10 2018-08-31 15305 SYRINGANETWORKS 2016-10-21 2018-08-25 25787 ROWE-NETWORKS 2016-10-21 2018-08-29 174 COGENT-174 2016-10-21 2018-08-22 271 BCNET 2016-10-24 2018-08-17 2828 XO-AS15 2016-10-25 2018-08-24 30341 SCTA-ASN 2016-10-31 2018-08-26 32440 LONI 2016-11-03 2018-08-29 33182 DimeNOC 2016-11-08 2018-08-30 12083 WOW-INTERNET 2016-11-09 2018-08-31 1403 EBOX 2016-11-12 2018-08-19 22561 CENTURYLINK-LEGACY-LIGHTCORE 2016-11-27 2018-08-06 21947 BCI 2017-01-06 2018-08-27 7106 INDEPENDENTSFIBERNETWORK 2017-01-09 2018-08-17 9009 M247 2017-01-10 2018-08-24 21832 KELLINCOM-1 2017-02-03 2018-08-25 7122 MTS-ASN 2017-05-16 2018-08-27 701 UUNET 2017-06-14 2018-08-13 22402 NEXTCO 2017-06-19 2018-08-16 6461 ZAYO-6461 2017-06-21 2018-08-28 20394 MASHELL-TELECOM 2017-06-29 2018-08-07 63296 AMARILLO-WIRELESS 2017-09-01 2018-08-30 7233 YAHOO-US 2017-09-07 2018-08-09 2152 CSUNET-NW 2017-11-08 2018-08-30 546 PARSONS-PGS-1 2017-11-20 2018-08-29 54540 INCERO 2018-01-15 2018-08-27 12222 AKAMAI 2018-02-14 2018-08-31 3257 GTT-BACKBONE 2018-03-06 2018-08-31 29384 Qatar-Foundation 2018-03-08 2018-08-26 23148 TERRENAP 2018-03-15 2018-08-30 54417 STIMULUS-TECHNOLOGIES 2018-03-29 2018-08-28 20009 WADSNET 2018-04-13 2018-08-29 4201 ORST 2018-04-19 2018-08-24 11827 WSU 2018-04-19 2018-08-29 393564 SPOKANE 2018-06-05 2018-08-15 35911 BNQ-1 2018-06-06 2018-08-29 225 VIRGINIA 2018-06-18 2018-08-21 30174 UTA 2018-08-03 2018-08-10 22773 ASN-CXA-ALL-CCI-22773-RDC 2018-08-04 2018-08-28 33588 BRESNAN 2018-08-05 2018-08-05 22742 CT-EDU-NET 2018-08-08 2018-08-29 53646 HARRIS-BROADBAND 2018-08-10 2018-08-10 55053 COLOWAREHOUSEONTARIO 2018-08-14 2018-08-15 54804 CSMIII-BUNKIELA 2018-08-21 2018-08-30 20057 ATT-MOBILITY-LLC-AS20057 2018-08-23 2018-08-23 15320 PRIMELINK 2018-08-23 2018-08-23 17025 ZAYO-CUSTOMER-17025 2018-08-23 2018-08-23 33452 RW 2018-08-24 2018-08-24 11260 EASTLINK-HSI 2018-08-26 2018-08-26 11996 LOBOIS 2018-08-28 2018-08-28 394153 VELOXINET 2018-08-28 2018-08-28 20448 VPNTRANET-LLC 2018-08-29 2018-08-29 40911 L2NC 2018-08-31 2018-08-31 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 benoit.garcia at gmail.com Mon Sep 10 15:38:01 2018 From: benoit.garcia at gmail.com (Benoit Garcia) Date: Mon, 10 Sep 2018 17:38:01 +0200 Subject: Proofpoint Contact? Message-ID: Hello, Could a Proofpoint e-mail blacklist contact me off list? I'm looking for some help to solve an undelivered email issue. Thanks in advance. -- Regards, Benoit. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarenangerbauer at gmail.com Mon Sep 10 16:23:13 2018 From: jarenangerbauer at gmail.com (Jaren Angerbauer) Date: Mon, 10 Sep 2018 10:23:13 -0600 Subject: Proofpoint Contact? In-Reply-To: References: Message-ID: On Mon, Sep 10, 2018 at 10:18 AM Benoit Garcia wrote: > Hello, > > Could a Proofpoint e-mail blacklist contact me off list? > I'm looking for some help to solve an undelivered email issue. > > Thanks in advance. > -- > Regards, > Benoit. > Replied off list. --Jaren -------------- next part -------------- An HTML attachment was scrubbed... URL: From darin.steffl at mnwifi.com Tue Sep 11 04:11:01 2018 From: darin.steffl at mnwifi.com (Darin Steffl) Date: Mon, 10 Sep 2018 23:11:01 -0500 Subject: OpenDNS CGNAT Issues Message-ID: Hello, I have a ticket open with OpenDNS about filtering happening on some of our CGNAT IP space where a customer has "claimed" the IP as theirs so other customers using that same IP and OpenDNS are being filtered and not able to access sites that fall under their chosen filter. I have a ticket open from 6 days ago but it's not going anywhere fast. Can someone from OpenDNS contact me or point me to a contact there to help get this resolved? I believe we need to claim our CGNAT IP space so residential users can't claim IP's of their own. Thank you! -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi Like us on Facebook -------------- next part -------------- An HTML attachment was scrubbed... URL: From marka at isc.org Tue Sep 11 06:30:40 2018 From: marka at isc.org (Mark Andrews) Date: Tue, 11 Sep 2018 16:30:40 +1000 Subject: QWEST you have broken DNS servers Message-ID: <0777B4F2-E71F-467A-9A55-351DEFDA2526@isc.org> I know it takes some time to upgrade DNS servers to ones that are actually protocol compliant but 4+ years is ridiculous. Your servers are the only ones serving the Alexa top 1M sites or the GOV zone that still return BADVERS to EDNS queries with a EDNS option present. This was behaviour made up by your DNS vendor. The correct response to EDNS options that are not understood is to IGNORE them. This allows clients and servers to deploy support for new options independently of each other. Additionally this is breaking DNSSEC validation of the signed zones your clients have you serving. They expect you to be using EDNS compliant name servers for this role which you are not. No, we are not working around this breakage in the resolver. Mark % dig soa frc.gov. @208.44.130.121 +norec ; <<>> DiG 9.12.1 <<>> soa frc.gov. @208.44.130.121 +norec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: BADVERS, id: 59707 ;; flags: qr ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; Query time: 66 msec ;; SERVER: 208.44.130.121#53(208.44.130.121) ;; WHEN: Tue Sep 11 06:08:41 UTC 2018 ;; MSG SIZE rcvd: 23 % dig soa frc.gov. @208.44.130.121 +norec +nocookie ; <<>> DiG 9.12.1 <<>> soa frc.gov. @208.44.130.121 +norec +nocookie ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16876 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;frc.gov. IN SOA ;; ANSWER SECTION: frc.gov. 86400 IN SOA sauthns2.qwest.net. dns-admin.qwestip.net. 2180320527 10800 3600 604800 86400 ;; AUTHORITY SECTION: frc.gov. 86400 IN NS sauthns1.qwest.net. frc.gov. 86400 IN NS sauthns2.qwest.net. ;; Query time: 66 msec ;; SERVER: 208.44.130.121#53(208.44.130.121) ;; WHEN: Tue Sep 11 06:19:33 UTC 2018 ;; MSG SIZE rcvd: 145 % grep ednsopt=badvers reports/alexa1m.2018-08-26T00:00:06Z | grep edns=ok | awk '{print $3}' | sort -u (sauthns1.qwest.net.): (sauthns2.qwest.net.): % grep ednsopt=badvers reports-full/gov-full.2018-09-11T00:00:06Z | grep edns=ok | awk '{print $3}' | sort -u (sauthns1.qwest.net.): (sauthns2.qwest.net.): % -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Tue Sep 11 07:05:33 2018 From: marka at isc.org (Mark Andrews) Date: Tue, 11 Sep 2018 17:05:33 +1000 Subject: Microsoft your DNS servers are broken Message-ID: <2FAC53CB-D346-4D94-A215-B7CFCF97E62A@isc.org> While we are talking about DNS server that are broken, Microsoft your servers are as well. As none of the zones you serve are DNSSEC signed there isn’t as much breakage possible but there are still interoperability problems and unnecessary additional traffic. It’s not like the EDNS specification is complicated. The microsoftonline servers will cause DNSSEC validation to fail if they ever serve a DNSSEC signed zone in this state. The FORMERR will cause EDNS servers to fallback to plain DNS and the validators won’t get the records they need. The azure servers cause problems for anyone deploying a new EDNS options as they have to cope with your servers incorrectly echoing back the option. Additionally if EDNS(1) is ever deployed there is a good chance that resolvers will assume the broken answers indicate that there is no data at the name. Mark cityofharrison-mi.gov. @207.46.15.59 (ns1.bdm.microsoftonline.com.): dns=ok edns=ok edns1=ok edns at 512=ok ednsopt=formerr,echoed edns1opt=formerr,version-not-zero,echoed do=ok ednsflags=ok optlist=formerr,subnet signed=ok ednstcp=ok cityofharrison-mi.gov. @2a01:111:f406:1804::59 (ns1.bdm.microsoftonline.com.): dns=ok edns=ok edns1=ok edns at 512=ok ednsopt=formerr,echoed edns1opt=formerr,version-not-zero,echoed do=ok ednsflags=ok optlist=formerr,subnet signed=ok ednstcp=ok cityofharrison-mi.gov. @191.232.83.138 (ns3.bdm.microsoftonline.com.): dns=ok edns=ok edns1=ok edns at 512=ok ednsopt=formerr,echoed edns1opt=formerr,version-not-zero,echoed do=ok ednsflags=ok optlist=formerr,subnet signed=ok ednstcp=ok cityofharrison-mi.gov. @2a01:111:f406:b400::22 (ns3.bdm.microsoftonline.com.): dns=ok edns=ok edns1=ok edns at 512=ok ednsopt=formerr,echoed edns1opt=formerr,version-not-zero,echoed do=ok ednsflags=ok optlist=formerr,subnet signed=ok ednstcp=ok cityofharrison-mi.gov. @157.56.81.41 (ns2.bdm.microsoftonline.com.): dns=ok edns=ok edns1=ok edns at 512=ok ednsopt=formerr,echoed edns1opt=formerr,version-not-zero,echoed do=ok ednsflags=ok optlist=formerr,subnet signed=ok ednstcp=ok cityofharrison-mi.gov. @2a01:111:f406:3403::41 (ns2.bdm.microsoftonline.com.): dns=ok edns=ok edns1=ok edns at 512=ok ednsopt=formerr,echoed edns1opt=formerr,version-not-zero,echoed do=ok ednsflags=ok optlist=formerr,subnet signed=ok ednstcp=ok clintoncounty-ia.gov. @13.107.24.7 (ns3-07.azure-dns.org.): dns=ok edns=ok edns1=noerror,badversion edns at 512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok clintoncounty-ia.gov. @2a01:111:4000::7 (ns3-07.azure-dns.org.): dns=ok edns=ok edns1=noerror,badversion edns at 512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok clintoncounty-ia.gov. @13.107.160.7 (ns4-07.azure-dns.info.): dns=ok edns=ok edns1=noerror,badversion edns at 512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok clintoncounty-ia.gov. @2620:1ec:bda::7 (ns4-07.azure-dns.info.): dns=ok edns=ok edns1=noerror,badversion edns at 512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok clintoncounty-ia.gov. @64.4.48.7 (ns2-07.azure-dns.net.): dns=ok edns=ok edns1=noerror,badversion edns at 512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok clintoncounty-ia.gov. @2620:1ec:8ec::7 (ns2-07.azure-dns.net.): dns=ok edns=ok edns1=noerror,badversion edns at 512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok clintoncounty-ia.gov. @40.90.4.7 (ns1-07.azure-dns.com.): dns=ok edns=ok edns1=noerror,badversion edns at 512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok clintoncounty-ia.gov. @2603:1061::7 (ns1-07.azure-dns.com.): dns=ok edns=ok edns1=noerror,badversion edns at 512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mehmet at akcin.net Tue Sep 11 07:14:25 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 11 Sep 2018 00:14:25 -0700 Subject: Microsoft your DNS servers are broken In-Reply-To: <2FAC53CB-D346-4D94-A215-B7CFCF97E62A@isc.org> References: <2FAC53CB-D346-4D94-A215-B7CFCF97E62A@isc.org> Message-ID: I have forwarded this to my contacts at Microsoft. On Tue, Sep 11, 2018 at 12:06 AM Mark Andrews wrote: > While we are talking about DNS server that are broken, Microsoft your > servers are as well. As none > of the zones you serve are DNSSEC signed there isn’t as much breakage > possible but there are still > interoperability problems and unnecessary additional traffic. It’s not > like the EDNS specification > is complicated. > > The microsoftonline servers will cause DNSSEC validation to fail if they > ever serve a DNSSEC signed > zone in this state. The FORMERR will cause EDNS servers to fallback to > plain DNS and the validators > won’t get the records they need. > > The azure servers cause problems for anyone deploying a new EDNS options > as they have to cope with > your servers incorrectly echoing back the option. Additionally if EDNS(1) > is ever deployed there is > a good chance that resolvers will assume the broken answers indicate that > there is no data at the > name. > > Mark > > cityofharrison-mi.gov. @207.46.15.59 (ns1.bdm.microsoftonline.com.): > dns=ok edns=ok edns1=ok edns at 512=ok ednsopt=formerr,echoed > edns1opt=formerr,version-not-zero,echoed do=ok ednsflags=ok > optlist=formerr,subnet signed=ok ednstcp=ok > cityofharrison-mi.gov. @2a01:111:f406:1804::59 ( > ns1.bdm.microsoftonline.com.): dns=ok edns=ok edns1=ok edns at 512=ok > ednsopt=formerr,echoed edns1opt=formerr,version-not-zero,echoed do=ok > ednsflags=ok optlist=formerr,subnet signed=ok ednstcp=ok > cityofharrison-mi.gov. @191.232.83.138 (ns3.bdm.microsoftonline.com.): > dns=ok edns=ok edns1=ok edns at 512=ok ednsopt=formerr,echoed > edns1opt=formerr,version-not-zero,echoed do=ok ednsflags=ok > optlist=formerr,subnet signed=ok ednstcp=ok > cityofharrison-mi.gov. @2a01:111:f406:b400::22 ( > ns3.bdm.microsoftonline.com.): dns=ok edns=ok edns1=ok edns at 512=ok > ednsopt=formerr,echoed edns1opt=formerr,version-not-zero,echoed do=ok > ednsflags=ok optlist=formerr,subnet signed=ok ednstcp=ok > cityofharrison-mi.gov. @157.56.81.41 (ns2.bdm.microsoftonline.com.): > dns=ok edns=ok edns1=ok edns at 512=ok ednsopt=formerr,echoed > edns1opt=formerr,version-not-zero,echoed do=ok ednsflags=ok > optlist=formerr,subnet signed=ok ednstcp=ok > cityofharrison-mi.gov. @2a01:111:f406:3403::41 ( > ns2.bdm.microsoftonline.com.): dns=ok edns=ok edns1=ok edns at 512=ok > ednsopt=formerr,echoed edns1opt=formerr,version-not-zero,echoed do=ok > ednsflags=ok optlist=formerr,subnet signed=ok ednstcp=ok > > clintoncounty-ia.gov. @13.107.24.7 (ns3-07.azure-dns.org.): dns=ok > edns=ok edns1=noerror,badversion edns at 512=ok ednsopt=echoed > edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok > ednstcp=ok > clintoncounty-ia.gov. @2a01:111:4000::7 (ns3-07.azure-dns.org.): dns=ok > edns=ok edns1=noerror,badversion edns at 512=ok ednsopt=echoed > edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok > ednstcp=ok > clintoncounty-ia.gov. @13.107.160.7 (ns4-07.azure-dns.info.): dns=ok > edns=ok edns1=noerror,badversion edns at 512=ok ednsopt=echoed > edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok > ednstcp=ok > clintoncounty-ia.gov. @2620:1ec:bda::7 (ns4-07.azure-dns.info.): dns=ok > edns=ok edns1=noerror,badversion edns at 512=ok ednsopt=echoed > edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok > ednstcp=ok > clintoncounty-ia.gov. @64.4.48.7 (ns2-07.azure-dns.net.): dns=ok edns=ok > edns1=noerror,badversion edns at 512=ok ednsopt=echoed > edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok > ednstcp=ok > clintoncounty-ia.gov. @2620:1ec:8ec::7 (ns2-07.azure-dns.net.): dns=ok > edns=ok edns1=noerror,badversion edns at 512=ok ednsopt=echoed > edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok > ednstcp=ok > clintoncounty-ia.gov. @40.90.4.7 (ns1-07.azure-dns.com.): dns=ok edns=ok > edns1=noerror,badversion edns at 512=ok ednsopt=echoed > edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok > ednstcp=ok > clintoncounty-ia.gov. @2603:1061::7 (ns1-07.azure-dns.com.): dns=ok > edns=ok edns1=noerror,badversion edns at 512=ok ednsopt=echoed > edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok > ednstcp=ok > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahebert at pubnix.net Tue Sep 11 12:48:06 2018 From: ahebert at pubnix.net (Alain Hebert) Date: Tue, 11 Sep 2018 08:48:06 -0400 Subject: Bell Canada IP transit - NID required? In-Reply-To: <1536505483_552546@surgemail.mnsi.net> References: <8FE29084-F45D-473B-9828-5B66083B544D@me.com> <1536505483_552546@surgemail.mnsi.net> Message-ID: <258ae60f-5948-3bcc-9854-630bbfda8bbd@pubnix.net>     Depending on the Colo...  It is generally a fiber for everyone.     But Bell being Bell (wink wink) I'm sure they made this extra and for no reason at all. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 09/09/18 11:04, Clayton Zekelman wrote: > > We used to have a GigE transit port terminated on CO connecting links > inside one of their COs long ago.  No CPE.  They may have changed > their policy since then. > > At 07:25 PM 08/09/2018, JASON BOTHE via NANOG wrote: > >> All, >> >> Just curious if anyone uses Bell Canada for IP transit in a colo >> environment and whether or not you were able to obtain a traditional >> cross-connect without having Bell place a managed CPE device in your >> cage. I can’t seem to find anyone intelligent enough to tell my any >> different other than “it’s never been done before” and “we >> need remote testing capabilities.” >> >> J~ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cb.list6 at gmail.com Tue Sep 11 12:54:39 2018 From: cb.list6 at gmail.com (Ca By) Date: Tue, 11 Sep 2018 05:54:39 -0700 Subject: OpenDNS CGNAT Issues In-Reply-To: References: Message-ID: On Mon, Sep 10, 2018 at 9:12 PM Darin Steffl wrote: > Hello, > > I have a ticket open with OpenDNS about filtering happening on some of our > CGNAT IP space where a customer has "claimed" the IP as theirs so other > customers using that same IP and OpenDNS are being filtered and not able to > access sites that fall under their chosen filter. > > I have a ticket open from 6 days ago but it's not going anywhere fast. > > Can someone from OpenDNS contact me or point me to a contact there to help > get this resolved? I believe we need to claim our CGNAT IP space so > residential users can't claim IP's of their own. > > Thank you! > You should provide your users ipv6, opendns supports ipv6 and likely will not have this issue you see https://www.opendns.com/about/innovations/ipv6/ I am sure it may cost you time / money / effort. But this old thing we call ipv4 is in a death spiral, and it will just get worse and worse for you without ipv6. > > -- > Darin Steffl > Minnesota WiFi > www.mnwifi.com > 507-634-WiFi > Like us on Facebook > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattlists at rivervalleyinternet.net Tue Sep 11 13:04:33 2018 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Tue, 11 Sep 2018 09:04:33 -0400 Subject: OpenDNS CGNAT Issues In-Reply-To: References: Message-ID: <40FBC3A3-FE91-4CFA-8DAE-314D05CEF942@rivervalleyinternet.net> That isn’t a solution. He still will need to dual stack and CGNat that. > On Sep 11, 2018, at 08:54, Ca By wrote: > > > >> On Mon, Sep 10, 2018 at 9:12 PM Darin Steffl wrote: >> Hello, >> >> I have a ticket open with OpenDNS about filtering happening on some of our CGNAT IP space where a customer has "claimed" the IP as theirs so other customers using that same IP and OpenDNS are being filtered and not able to access sites that fall under their chosen filter. >> >> I have a ticket open from 6 days ago but it's not going anywhere fast. >> >> Can someone from OpenDNS contact me or point me to a contact there to help get this resolved? I believe we need to claim our CGNAT IP space so residential users can't claim IP's of their own. >> >> Thank you! > > You should provide your users ipv6, opendns supports ipv6 and likely will not have this issue you see > > https://www.opendns.com/about/innovations/ipv6/ > > I am sure it may cost you time / money / effort. But this old thing we call ipv4 is in a death spiral, and it will just get worse and worse for you without ipv6. > > >> >> >> -- >> Darin Steffl >> Minnesota WiFi >> www.mnwifi.com >> 507-634-WiFi >> Like us on Facebook -------------- next part -------------- An HTML attachment was scrubbed... URL: From cb.list6 at gmail.com Tue Sep 11 13:28:42 2018 From: cb.list6 at gmail.com (Ca By) Date: Tue, 11 Sep 2018 06:28:42 -0700 Subject: OpenDNS CGNAT Issues In-Reply-To: <40FBC3A3-FE91-4CFA-8DAE-314D05CEF942@rivervalleyinternet.net> References: <40FBC3A3-FE91-4CFA-8DAE-314D05CEF942@rivervalleyinternet.net> Message-ID: On Tue, Sep 11, 2018 at 6:04 AM Matt Hoppes < mattlists at rivervalleyinternet.net> wrote: > That isn’t a solution. He still will need to dual stack and CGNat that. > But the flows that can support ipv6, will go ipv6 and not be subject to these abuse triggers. Look, this list has monthly reports from some small network operator hurting their customers with CGN NAT. Meanwhile, the big guys like Comcast / Charter / ATT / Cox have moved onto ipv6. Where does that leave the little guy with CGN? Right here. Screaming into the avoid begging for help. Some special exception. And, me, saying you had 10+ years of not deploying ipv6. Here’s to the next 10 years of you email this list about your own failure to keep up with the times. We will have this discussion again and again. Not sure your customers will stick around, all they know is your CGN space got black listed from yet another service #realtalk > On Sep 11, 2018, at 08:54, Ca By wrote: > > > > On Mon, Sep 10, 2018 at 9:12 PM Darin Steffl > wrote: > >> Hello, >> >> I have a ticket open with OpenDNS about filtering happening on some of >> our CGNAT IP space where a customer has "claimed" the IP as theirs so other >> customers using that same IP and OpenDNS are being filtered and not able to >> access sites that fall under their chosen filter. >> >> I have a ticket open from 6 days ago but it's not going anywhere fast. >> >> Can someone from OpenDNS contact me or point me to a contact there to >> help get this resolved? I believe we need to claim our CGNAT IP space so >> residential users can't claim IP's of their own. >> >> Thank you! >> > > You should provide your users ipv6, opendns supports ipv6 and likely will > not have this issue you see > > https://www.opendns.com/about/innovations/ipv6/ > > I am sure it may cost you time / money / effort. But this old thing we > call ipv4 is in a death spiral, and it will just get worse and worse for > you without ipv6. > > > >> >> -- >> Darin Steffl >> Minnesota WiFi >> www.mnwifi.com >> 507-634-WiFi >> Like us on Facebook >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattlists at rivervalleyinternet.net Tue Sep 11 13:31:56 2018 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Tue, 11 Sep 2018 09:31:56 -0400 Subject: OpenDNS CGNAT Issues In-Reply-To: References: <40FBC3A3-FE91-4CFA-8DAE-314D05CEF942@rivervalleyinternet.net> Message-ID: So don't CGNat? Buy IPv4 addresses at auction? On 9/11/18 9:28 AM, Ca By wrote: > > > On Tue, Sep 11, 2018 at 6:04 AM Matt Hoppes > > wrote: > > That isn’t a solution. He still will need to dual stack and CGNat that. > > > But the flows that can support ipv6, will go ipv6 and not be subject to > these abuse triggers. > > Look, this list has monthly reports from some small network operator > hurting their customers with CGN NAT. Meanwhile, the big guys like > Comcast / Charter / ATT / Cox have moved onto ipv6. > > Where does that leave the little guy with CGN? > > Right here. Screaming into the avoid begging for help. Some special > exception. > > And, me, saying you had 10+ years of not deploying ipv6.  Here’s to the > next 10 years of you email this list about your own failure to keep up > with the times. > > We will have this discussion again and again.  Not sure your customers > will stick around, all they know is your CGN space got black listed from > yet another service > > #realtalk > > > On Sep 11, 2018, at 08:54, Ca By > wrote: > >> >> >> On Mon, Sep 10, 2018 at 9:12 PM Darin Steffl >> > wrote: >> >> Hello, >> >> I have a ticket open with OpenDNS about filtering happening on >> some of our CGNAT IP space where a customer has "claimed" the >> IP as theirs so other customers using that same IP and OpenDNS >> are being filtered and not able to access sites that fall >> under their chosen filter. >> >> I have a ticket open from 6 days ago but it's not going >> anywhere fast. >> >> Can someone from OpenDNS contact me or point me to a contact >> there to help get this resolved? I believe we need to claim >> our CGNAT IP space so residential users can't claim IP's of >> their own. >> >> Thank you! >> >> >> You should provide your users ipv6, opendns supports ipv6 and >> likely will not have this issue you see >> >> https://www.opendns.com/about/innovations/ipv6/ >> >> I am sure it may cost you time / money / effort. But this old >> thing we call ipv4 is in a death spiral, and it will just get >> worse and worse for you without ipv6. >> >> >> >> >> -- >> Darin Steffl >> Minnesota WiFi >> www.mnwifi.com >> 507-634-WiFi >> Like us on Facebook >> >> From cb.list6 at gmail.com Tue Sep 11 13:39:37 2018 From: cb.list6 at gmail.com (Ca By) Date: Tue, 11 Sep 2018 06:39:37 -0700 Subject: OpenDNS CGNAT Issues In-Reply-To: References: <40FBC3A3-FE91-4CFA-8DAE-314D05CEF942@rivervalleyinternet.net> Message-ID: On Tue, Sep 11, 2018 at 6:31 AM Matt Hoppes < mattlists at rivervalleyinternet.net> wrote: > So don't CGNat? Buy IPv4 addresses at auction? > As long as you don’t deploy ipv6, you should be good. Seriously. Not sure why this is so hard. IPv4 does not scale. Your customers, like my customers, probably mostly go to Youtube, google, fb, netflix, .... all which have ipv6. Giving your existing customers ipv6 moves this traffic off your cgn. And gives them a path to dns services. But you do you. if you ask NANOG, how to solve this problem, and missed the 3 NANOG meeting presos at every meeting about how ipv6 is good .... not sure what you expect here. Definately not a shoulder to cry on, but i wm sure some v4 brokers and cgn box pushers see your customers blood in the water. CB > > On 9/11/18 9:28 AM, Ca By wrote: > > > > > > On Tue, Sep 11, 2018 at 6:04 AM Matt Hoppes > > > > wrote: > > > > That isn’t a solution. He still will need to dual stack and CGNat > that. > > > > > > But the flows that can support ipv6, will go ipv6 and not be subject to > > these abuse triggers. > > > > Look, this list has monthly reports from some small network operator > > hurting their customers with CGN NAT. Meanwhile, the big guys like > > Comcast / Charter / ATT / Cox have moved onto ipv6. > > > > Where does that leave the little guy with CGN? > > > > Right here. Screaming into the avoid begging for help. Some special > > exception. > > > > And, me, saying you had 10+ years of not deploying ipv6. Here’s to the > > next 10 years of you email this list about your own failure to keep up > > with the times. > > > > We will have this discussion again and again. Not sure your customers > > will stick around, all they know is your CGN space got black listed from > > yet another service > > > > #realtalk > > > > > > On Sep 11, 2018, at 08:54, Ca By > > wrote: > > > >> > >> > >> On Mon, Sep 10, 2018 at 9:12 PM Darin Steffl > >> > wrote: > >> > >> Hello, > >> > >> I have a ticket open with OpenDNS about filtering happening on > >> some of our CGNAT IP space where a customer has "claimed" the > >> IP as theirs so other customers using that same IP and OpenDNS > >> are being filtered and not able to access sites that fall > >> under their chosen filter. > >> > >> I have a ticket open from 6 days ago but it's not going > >> anywhere fast. > >> > >> Can someone from OpenDNS contact me or point me to a contact > >> there to help get this resolved? I believe we need to claim > >> our CGNAT IP space so residential users can't claim IP's of > >> their own. > >> > >> Thank you! > >> > >> > >> You should provide your users ipv6, opendns supports ipv6 and > >> likely will not have this issue you see > >> > >> https://www.opendns.com/about/innovations/ipv6/ > >> > >> I am sure it may cost you time / money / effort. But this old > >> thing we call ipv4 is in a death spiral, and it will just get > >> worse and worse for you without ipv6. > >> > >> > >> > >> > >> -- > >> Darin Steffl > >> Minnesota WiFi > >> www.mnwifi.com > >> 507-634-WiFi > >> Like us on Facebook > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darin.steffl at mnwifi.com Tue Sep 11 14:22:52 2018 From: darin.steffl at mnwifi.com (Darin Steffl) Date: Tue, 11 Sep 2018 09:22:52 -0500 Subject: OpenDNS CGNAT Issues In-Reply-To: References: <40FBC3A3-FE91-4CFA-8DAE-314D05CEF942@rivervalleyinternet.net> Message-ID: Guys, I'm not asking about IPv6. I'm simply asking for a contact at OpenDNS. And we are purchasing enough IPv4 space to provide an IP to every customer but it's not ready yet. Thank you On Tue, Sep 11, 2018 at 8:39 AM, Ca By wrote: > > > On Tue, Sep 11, 2018 at 6:31 AM Matt Hoppes rivervalleyinternet.net> wrote: > >> So don't CGNat? Buy IPv4 addresses at auction? >> > > As long as you don’t deploy ipv6, you should be good. > > Seriously. Not sure why this is so hard. IPv4 does not scale. Your > customers, like my customers, probably mostly go to Youtube, google, fb, > netflix, .... all which have ipv6. Giving your existing customers ipv6 > moves this traffic off your cgn. And gives them a path to dns services. > > But you do you. if you ask NANOG, how to solve this problem, and missed > the 3 NANOG meeting presos at every meeting about how ipv6 is good .... not > sure what you expect here. Definately not a shoulder to cry on, but i wm > sure some v4 brokers and cgn box pushers see your customers blood in the > water. > > CB > >> >> On 9/11/18 9:28 AM, Ca By wrote: >> > >> > >> > On Tue, Sep 11, 2018 at 6:04 AM Matt Hoppes >> > > > > wrote: >> > >> > That isn’t a solution. He still will need to dual stack and CGNat >> that. >> > >> > >> > But the flows that can support ipv6, will go ipv6 and not be subject to >> > these abuse triggers. >> > >> > Look, this list has monthly reports from some small network operator >> > hurting their customers with CGN NAT. Meanwhile, the big guys like >> > Comcast / Charter / ATT / Cox have moved onto ipv6. >> > >> > Where does that leave the little guy with CGN? >> > >> > Right here. Screaming into the avoid begging for help. Some special >> > exception. >> > >> > And, me, saying you had 10+ years of not deploying ipv6. Here’s to the >> > next 10 years of you email this list about your own failure to keep up >> > with the times. >> > >> > We will have this discussion again and again. Not sure your customers >> > will stick around, all they know is your CGN space got black listed >> from >> > yet another service >> > >> > #realtalk >> > >> > >> > On Sep 11, 2018, at 08:54, Ca By > > > wrote: >> > >> >> >> >> >> >> On Mon, Sep 10, 2018 at 9:12 PM Darin Steffl >> >> > wrote: >> >> >> >> Hello, >> >> >> >> I have a ticket open with OpenDNS about filtering happening on >> >> some of our CGNAT IP space where a customer has "claimed" the >> >> IP as theirs so other customers using that same IP and OpenDNS >> >> are being filtered and not able to access sites that fall >> >> under their chosen filter. >> >> >> >> I have a ticket open from 6 days ago but it's not going >> >> anywhere fast. >> >> >> >> Can someone from OpenDNS contact me or point me to a contact >> >> there to help get this resolved? I believe we need to claim >> >> our CGNAT IP space so residential users can't claim IP's of >> >> their own. >> >> >> >> Thank you! >> >> >> >> >> >> You should provide your users ipv6, opendns supports ipv6 and >> >> likely will not have this issue you see >> >> >> >> https://www.opendns.com/about/innovations/ipv6/ >> >> >> >> I am sure it may cost you time / money / effort. But this old >> >> thing we call ipv4 is in a death spiral, and it will just get >> >> worse and worse for you without ipv6. >> >> >> >> >> >> >> >> >> >> -- >> >> Darin Steffl >> >> Minnesota WiFi >> >> www.mnwifi.com >> >> 507-634-WiFi >> >> Like us on Facebook >> >> >> >> >> > -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi Like us on Facebook -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at wi-fiber.io Tue Sep 11 16:29:14 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Tue, 11 Sep 2018 10:29:14 -0600 Subject: OpenDNS CGNAT Issues In-Reply-To: References: <40FBC3A3-FE91-4CFA-8DAE-314D05CEF942@rivervalleyinternet.net> Message-ID: "Where does that leave the little guy with CGN? Right here. Screaming into the avoid begging for help. Some special exception. " As a group that you'd consider a "little" guy, we've always ran full dual stack ipv4/ipv6. The issue is being dual stack literally takes twice as long to configure everything, it causes twice as many potential routing problems, and you must now monitor twice as many routes, etc.. As a little guy who has to fight tooth and nail for every customer, we hardly have time in the day to run it this way, but we do, and guess what, every single day we get ipv4 issues. Not CGNAT ipv4 issues, we actually have not seen a single issue with CGNAT for our customer base, our techs ask a simple question at install, "what do you use the internet for?", "gaming", "Okay, dedicated public it is". And yet, with all those publics out there, we still get calls everyday about some site not letting them in. It's all ipv4 issues. So not only do we have to expend the energy to implement dual stack in our network, it doesn't save us any headaches. Until web hosting companies, and cloud services offer ipv6 only as the defacto instead of the premium service, only then will you see ipv4 not be an issue on the web. The reason you only see the little guys screaming into the void is because the big guys already have the contacts and already have the pull to get it resolved in hours. I've posted in another forum the need for us as an industry to have an association directly in charge of maintaining contacts at all associations that have a history of aggressive filtering, so issues like these don't take a little guy like us 2-4 weeks to resolve. If the little guys were all a part of this association, they would contact their membership rep for the contact and the membership rep would reach out as a representative of the group as a whole to resolve any IP filtering issue that occurs. Anything less than that will continue to have this forum clogged with requests like these. Michael On Tue, 11 Sep 2018 at 07:31, Ca By wrote: > > > On Tue, Sep 11, 2018 at 6:04 AM Matt Hoppes < > mattlists at rivervalleyinternet.net> wrote: > >> That isn’t a solution. He still will need to dual stack and CGNat that. >> > > But the flows that can support ipv6, will go ipv6 and not be subject to > these abuse triggers. > > Look, this list has monthly reports from some small network operator > hurting their customers with CGN NAT. Meanwhile, the big guys like Comcast > / Charter / ATT / Cox have moved onto ipv6. > > Where does that leave the little guy with CGN? > > Right here. Screaming into the avoid begging for help. Some special > exception. > > And, me, saying you had 10+ years of not deploying ipv6. Here’s to the > next 10 years of you email this list about your own failure to keep up with > the times. > > We will have this discussion again and again. Not sure your customers > will stick around, all they know is your CGN space got black listed from > yet another service > > #realtalk > > >> On Sep 11, 2018, at 08:54, Ca By wrote: >> >> >> >> On Mon, Sep 10, 2018 at 9:12 PM Darin Steffl >> wrote: >> >>> Hello, >>> >>> I have a ticket open with OpenDNS about filtering happening on some of >>> our CGNAT IP space where a customer has "claimed" the IP as theirs so other >>> customers using that same IP and OpenDNS are being filtered and not able to >>> access sites that fall under their chosen filter. >>> >>> I have a ticket open from 6 days ago but it's not going anywhere fast. >>> >>> Can someone from OpenDNS contact me or point me to a contact there to >>> help get this resolved? I believe we need to claim our CGNAT IP space so >>> residential users can't claim IP's of their own. >>> >>> Thank you! >>> >> >> You should provide your users ipv6, opendns supports ipv6 and likely will >> not have this issue you see >> >> https://www.opendns.com/about/innovations/ipv6/ >> >> I am sure it may cost you time / money / effort. But this old thing we >> call ipv4 is in a death spiral, and it will just get worse and worse for >> you without ipv6. >> >> >> >>> >>> -- >>> Darin Steffl >>> Minnesota WiFi >>> www.mnwifi.com >>> 507-634-WiFi >>> Like us on Facebook >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From aled.w.morris at googlemail.com Tue Sep 11 13:07:27 2018 From: aled.w.morris at googlemail.com (Aled Morris) Date: Tue, 11 Sep 2018 14:07:27 +0100 Subject: OpenDNS CGNAT Issues In-Reply-To: References: Message-ID: On Tue, 11 Sep 2018 at 13:56, Ca By wrote: > You should provide your users ipv6, opendns supports ipv6 and likely will > not have this issue you see > OpenDNS does not support IPv6 for their customisable services "Home" etc. which I believe is the service the OP is using as he refers to the end-user wanting to register their IP address. Incidentally, I hope OpenDNS considers 100.64.0.0/10 as space that can't be registered to any end-user. Aled -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Wed Sep 12 02:42:58 2018 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 11 Sep 2018 22:42:58 -0400 Subject: OpenDNS CGNAT Issues In-Reply-To: References: <40FBC3A3-FE91-4CFA-8DAE-314D05CEF942@rivervalleyinternet.net> Message-ID: The reason you are asking is because of a technical decision you have made that would be mitigated partially by deploying V6. I get you may not care, may not like the message but all the people who are having more problems because of this and other decisions you make in this area are driving up the price of v4 and also making more work for yourselves in the long term. Jared Mauch > On Sep 11, 2018, at 10:22 AM, Darin Steffl wrote: > > Guys, I'm not asking about IPv6. I'm simply asking for a contact at OpenDNS. > > And we are purchasing enough IPv4 space to provide an IP to every customer but it's not ready yet. > > Thank you > >> On Tue, Sep 11, 2018 at 8:39 AM, Ca By wrote: >> >> >>> On Tue, Sep 11, 2018 at 6:31 AM Matt Hoppes wrote: >>> So don't CGNat? Buy IPv4 addresses at auction? >> >> As long as you don’t deploy ipv6, you should be good. >> >> Seriously. Not sure why this is so hard. IPv4 does not scale. Your customers, like my customers, probably mostly go to Youtube, google, fb, netflix, .... all which have ipv6. Giving your existing customers ipv6 moves this traffic off your cgn. And gives them a path to dns services. >> >> But you do you. if you ask NANOG, how to solve this problem, and missed the 3 NANOG meeting presos at every meeting about how ipv6 is good .... not sure what you expect here. Definately not a shoulder to cry on, but i wm sure some v4 brokers and cgn box pushers see your customers blood in the water. >> >> CB >>> >>> On 9/11/18 9:28 AM, Ca By wrote: >>> > >>> > >>> > On Tue, Sep 11, 2018 at 6:04 AM Matt Hoppes >>> > >> > > wrote: >>> > >>> > That isn’t a solution. He still will need to dual stack and CGNat that. >>> > >>> > >>> > But the flows that can support ipv6, will go ipv6 and not be subject to >>> > these abuse triggers. >>> > >>> > Look, this list has monthly reports from some small network operator >>> > hurting their customers with CGN NAT. Meanwhile, the big guys like >>> > Comcast / Charter / ATT / Cox have moved onto ipv6. >>> > >>> > Where does that leave the little guy with CGN? >>> > >>> > Right here. Screaming into the avoid begging for help. Some special >>> > exception. >>> > >>> > And, me, saying you had 10+ years of not deploying ipv6. Here’s to the >>> > next 10 years of you email this list about your own failure to keep up >>> > with the times. >>> > >>> > We will have this discussion again and again. Not sure your customers >>> > will stick around, all they know is your CGN space got black listed from >>> > yet another service >>> > >>> > #realtalk >>> > >>> > >>> > On Sep 11, 2018, at 08:54, Ca By >> > > wrote: >>> > >>> >> >>> >> >>> >> On Mon, Sep 10, 2018 at 9:12 PM Darin Steffl >>> >> > wrote: >>> >> >>> >> Hello, >>> >> >>> >> I have a ticket open with OpenDNS about filtering happening on >>> >> some of our CGNAT IP space where a customer has "claimed" the >>> >> IP as theirs so other customers using that same IP and OpenDNS >>> >> are being filtered and not able to access sites that fall >>> >> under their chosen filter. >>> >> >>> >> I have a ticket open from 6 days ago but it's not going >>> >> anywhere fast. >>> >> >>> >> Can someone from OpenDNS contact me or point me to a contact >>> >> there to help get this resolved? I believe we need to claim >>> >> our CGNAT IP space so residential users can't claim IP's of >>> >> their own. >>> >> >>> >> Thank you! >>> >> >>> >> >>> >> You should provide your users ipv6, opendns supports ipv6 and >>> >> likely will not have this issue you see >>> >> >>> >> https://www.opendns.com/about/innovations/ipv6/ >>> >> >>> >> I am sure it may cost you time / money / effort. But this old >>> >> thing we call ipv4 is in a death spiral, and it will just get >>> >> worse and worse for you without ipv6. >>> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> Darin Steffl >>> >> Minnesota WiFi >>> >> www.mnwifi.com >>> >> 507-634-WiFi >>> >> Like us on Facebook >>> >> >>> >> > > > > -- > Darin Steffl > Minnesota WiFi > www.mnwifi.com > 507-634-WiFi > Like us on Facebook -------------- next part -------------- An HTML attachment was scrubbed... URL: From marka at isc.org Wed Sep 12 03:08:20 2018 From: marka at isc.org (Mark Andrews) Date: Wed, 12 Sep 2018 13:08:20 +1000 Subject: OpenDNS CGNAT Issues In-Reply-To: References: Message-ID: <17CB2714-9D92-43C5-92E7-02477FB094A4@isc.org> > On 11 Sep 2018, at 11:07 pm, Aled Morris via NANOG wrote: > > On Tue, 11 Sep 2018 at 13:56, Ca By wrote: > You should provide your users ipv6, opendns supports ipv6 and likely will not have this issue you see > > OpenDNS does not support IPv6 for their customisable services "Home" etc. which I believe is the service the OP is using as he refers to the end-user wanting to register their IP address. We really should get away from using IP addresses for identifying anything. At the DNS level you can use a EDNS option to identify the client rather than the IP address. I believe their Umbrella product does this. You can also use TSIG to identify clients independent of IP address. We added TSIG support to libresolv right at the beginning of the century. Mark > Incidentally, I hope OpenDNS considers 100.64.0.0/10 as space that can't be registered to any end-user. > > Aled -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jerry at jtcloe.net Wed Sep 12 04:05:38 2018 From: jerry at jtcloe.net (=?utf-8?Q?Jerry_Cloe?=) Date: Tue, 11 Sep 2018 23:05:38 -0500 Subject: OpenDNS CGNAT Issues In-Reply-To: References: Message-ID: OpenDNS, or anyone for that matter, should never see 100.64/10 ip's. If they do, something is wrong at the source, and OpenDNS wouldn't be able to reply anyway (or at least have the reply route back to the user).   -----Original message----- From:Aled Morris via NANOG Sent:Tue 09-11-2018 11:57 am Subject:Re: OpenDNS CGNAT Issues To:cb.list6 at gmail.com; CC:NANOG ;  Incidentally, I hope OpenDNS considers 100.64.0.0/10 as space that can't be registered to any end-user.  Aled -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Wed Sep 12 04:58:36 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 11 Sep 2018 21:58:36 -0700 Subject: OpenDNS CGNAT Issues In-Reply-To: References: Message-ID: On Tue, Sep 11, 2018 at 9:06 PM Jerry Cloe wrote: > OpenDNS, or anyone for that matter, should never see 100.64/10 ip's. If > they do, something is wrong at the source, and OpenDNS wouldn't be able to > reply anyway (or at least have the reply route back to the user). > maybeopendns peers directly with such an eyeball network? and in that case maybe they have an agreement to accept traffic from the 100.64 space? > > > -----Original message----- > *From:* Aled Morris via NANOG > *Sent:* Tue 09-11-2018 11:57 am > *Subject:* Re: OpenDNS CGNAT Issues > *To:* cb.list6 at gmail.com; > *CC:* NANOG ; > > Incidentally, I hope OpenDNS considers 100.64.0.0/10 as space that can't > be registered to any end-user. > > Aled > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed Sep 12 05:03:43 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 11 Sep 2018 22:03:43 -0700 Subject: OpenDNS CGNAT Issues In-Reply-To: References: Message-ID: > On Sep 11, 2018, at 21:58 , Christopher Morrow wrote: > > > > On Tue, Sep 11, 2018 at 9:06 PM Jerry Cloe > wrote: > OpenDNS, or anyone for that matter, should never see 100.64/10 ip's. If they do, something is wrong at the source, and OpenDNS wouldn't be able to reply anyway (or at least have the reply route back to the user). > > > maybeopendns peers directly with such an eyeball network? and in that case maybe they have an agreement to accept traffic from the 100.64 space? They’d only be able to do one such agreement per routing environment. Managing that would be _UGLY_ for the first one and __UGLY__ at scale for anything more than one. It also pretty much eliminates potential for geographic diversity and anycast for a provider in a local geography. Certainly not something I’d choose to do if I were OpenDNS unless someone arrived with a very large truck full of gold, diamonds, or other valuable hard assets. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Wed Sep 12 05:13:34 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 11 Sep 2018 22:13:34 -0700 Subject: OpenDNS CGNAT Issues In-Reply-To: References: Message-ID: On Tue, Sep 11, 2018 at 10:03 PM Owen DeLong wrote: > > > On Sep 11, 2018, at 21:58 , Christopher Morrow > wrote: > > > > On Tue, Sep 11, 2018 at 9:06 PM Jerry Cloe wrote: > >> OpenDNS, or anyone for that matter, should never see 100.64/10 ip's. If >> they do, something is wrong at the source, and OpenDNS wouldn't be able to >> reply anyway (or at least have the reply route back to the user). >> > > maybeopendns peers directly with such an eyeball network? and in that case > maybe they have an agreement to accept traffic from the 100.64 space? > > > They’d only be able to do one such agreement per routing environment. > > sure, I hear DNS servers are cheap and small, and easy to manage... > Managing that would be _UGLY_ for the first one and __UGLY__ at scale for > anything more than one. > > meh? it's a dns server stack and router(s) for peering to the customer + world... it's really not THAT hard to automate and deploy... and really for 'single customer' or 'non overlapping sets of customers' it's not like they need lots of horsepower here, right? this is ... simple to do, simple to manage and simple to maintain. > It also pretty much eliminates potential for geographic diversity and > anycast for a provider in a local geography. > > there are more than one building in the georgrahy, and probably/maybe these providers appear in more than one local, right? so... a dns provider can arrive in the right matrix of locations and connect + provide routing-data .... done. > Certainly not something I’d choose to do if I were OpenDNS unless someone > arrived with a very large truck full of gold, diamonds, or other valuable > hard assets. > > meh.. again, say the customer covers the cost of gear + network + maintenance for the previous parts.. .then it's just managing 'another' remote dns server .. .something I understand they do fairly well even? once you have a hundred of somethign deployed you are automated or .. you are doing it wrong. > Owen > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenny.taylor at kccd.edu Wed Sep 12 14:10:05 2018 From: kenny.taylor at kccd.edu (Kenny Taylor) Date: Wed, 12 Sep 2018 14:10:05 +0000 Subject: OpenDNS CGNAT Issues In-Reply-To: References: Message-ID: For a truckload of gold, I’m pretty sure most of us would make that work ☺ Kenny From: NANOG On Behalf Of Owen DeLong Sent: Tuesday, September 11, 2018 10:04 PM To: Christopher Morrow Cc: nanog list Subject: Re: OpenDNS CGNAT Issues On Sep 11, 2018, at 21:58 , Christopher Morrow > wrote: On Tue, Sep 11, 2018 at 9:06 PM Jerry Cloe > wrote: OpenDNS, or anyone for that matter, should never see 100.64/10 ip's. If they do, something is wrong at the source, and OpenDNS wouldn't be able to reply anyway (or at least have the reply route back to the user). maybeopendns peers directly with such an eyeball network? and in that case maybe they have an agreement to accept traffic from the 100.64 space? They’d only be able to do one such agreement per routing environment. Managing that would be _UGLY_ for the first one and __UGLY__ at scale for anything more than one. It also pretty much eliminates potential for geographic diversity and anycast for a provider in a local geography. Certainly not something I’d choose to do if I were OpenDNS unless someone arrived with a very large truck full of gold, diamonds, or other valuable hard assets. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed Sep 12 16:07:52 2018 From: owen at delong.com (Owen DeLong) Date: Wed, 12 Sep 2018 09:07:52 -0700 Subject: OpenDNS CGNAT Issues In-Reply-To: References: Message-ID: <51D33042-09A5-4AB4-8B5F-25F1246D44D0@delong.com> Sure… The point was that short of that, anyone in their right mind wouldn’t bother. Owen > On Sep 12, 2018, at 7:10 AM, Kenny Taylor wrote: > > For a truckload of gold, I’m pretty sure most of us would make that work J > > Kenny > > From: NANOG > On Behalf Of Owen DeLong > Sent: Tuesday, September 11, 2018 10:04 PM > To: Christopher Morrow > > Cc: nanog list > > Subject: Re: OpenDNS CGNAT Issues > > > > > On Sep 11, 2018, at 21:58 , Christopher Morrow > wrote: > > > > On Tue, Sep 11, 2018 at 9:06 PM Jerry Cloe > wrote: > OpenDNS, or anyone for that matter, should never see 100.64/10 ip's. If they do, something is wrong at the source, and OpenDNS wouldn't be able to reply anyway (or at least have the reply route back to the user). > > maybeopendns peers directly with such an eyeball network? and in that case maybe they have an agreement to accept traffic from the 100.64 space? > > They’d only be able to do one such agreement per routing environment. > > Managing that would be _UGLY_ for the first one and __UGLY__ at scale for anything more than one. > > It also pretty much eliminates potential for geographic diversity and anycast for a provider in a local geography. > > Certainly not something I’d choose to do if I were OpenDNS unless someone arrived with a very large truck full of gold, diamonds, or other valuable hard assets. > > Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Wed Sep 12 16:11:12 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 12 Sep 2018 12:11:12 -0400 Subject: OpenDNS CGNAT Issues In-Reply-To: References: Message-ID: <16875.1536768672@turing-police.cc.vt.edu> On Wed, 12 Sep 2018 14:10:05 -0000, Kenny Taylor said: > For a truckload of gold, I���m pretty sure most of us would make that work ��� Unless they get underbid by the one of us willing to settle for a foot locker full of gold. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From lee.howard at retevia.net Wed Sep 12 16:40:03 2018 From: lee.howard at retevia.net (Lee Howard) Date: Wed, 12 Sep 2018 12:40:03 -0400 Subject: OpenDNS CGNAT Issues In-Reply-To: References: <40FBC3A3-FE91-4CFA-8DAE-314D05CEF942@rivervalleyinternet.net> Message-ID: On 09/11/2018 09:31 AM, Matt Hoppes wrote: > So don't CGNat?  Buy IPv4 addresses at auction? Buy IPv4 addresses until CGN is cheaper. If a customer has to call, and you have to assign an IPv4 address, you have to recover the cost of that call and address. While ((CostOfCall + CostOfAddress)*NumberOfCalls) > (CostOfAddress*NumberOfNewCustomers):      BuyAddresses(NumberOfNewCustomers) Meanwhile, deploy IPv6, and move toward IPv4aaS, probably 464xlat or MAP, but your religion may vary. That way your "CGN" is an IPv6-IPv4 translator, and that's easier than managing dual-stack. At the very least, dual-stack your web sites now, so the rest of us can get to it without translation. Lee > > On 9/11/18 9:28 AM, Ca By wrote: >> >> >> On Tue, Sep 11, 2018 at 6:04 AM Matt Hoppes >> > > wrote: >> >>     That isn’t a solution. He still will need to dual stack and CGNat >> that. >> >> >> But the flows that can support ipv6, will go ipv6 and not be subject >> to these abuse triggers. >> >> Look, this list has monthly reports from some small network operator >> hurting their customers with CGN NAT. Meanwhile, the big guys like >> Comcast / Charter / ATT / Cox have moved onto ipv6. >> >> Where does that leave the little guy with CGN? >> >> Right here. Screaming into the avoid begging for help. Some special >> exception. >> >> And, me, saying you had 10+ years of not deploying ipv6.  Here’s to >> the next 10 years of you email this list about your own failure to >> keep up with the times. >> >> We will have this discussion again and again.  Not sure your >> customers will stick around, all they know is your CGN space got >> black listed from yet another service >> >> #realtalk >> >> >>     On Sep 11, 2018, at 08:54, Ca By >     > wrote: >> >>> >>> >>>     On Mon, Sep 10, 2018 at 9:12 PM Darin Steffl >>>     > wrote: >>> >>>         Hello, >>> >>>         I have a ticket open with OpenDNS about filtering happening on >>>         some of our CGNAT IP space where a customer has "claimed" the >>>         IP as theirs so other customers using that same IP and OpenDNS >>>         are being filtered and not able to access sites that fall >>>         under their chosen filter. >>> >>>         I have a ticket open from 6 days ago but it's not going >>>         anywhere fast. >>> >>>         Can someone from OpenDNS contact me or point me to a contact >>>         there to help get this resolved? I believe we need to claim >>>         our CGNAT IP space so residential users can't claim IP's of >>>         their own. >>> >>>         Thank you! >>> >>> >>>     You should provide your users ipv6, opendns supports ipv6 and >>>     likely will not have this issue you see >>> >>>     https://www.opendns.com/about/innovations/ipv6/ >>> >>>     I am sure it may cost you time / money / effort. But this old >>>     thing we call ipv4 is in a death spiral, and it will just get >>>     worse and worse for you without ipv6. >>> >>> >>> >>> >>>         --         Darin Steffl >>>         Minnesota WiFi >>>         www.mnwifi.com >>>         507-634-WiFi >>>         Like us on Facebook >>>         >>> > > From owen at delong.com Wed Sep 12 16:42:11 2018 From: owen at delong.com (Owen DeLong) Date: Wed, 12 Sep 2018 09:42:11 -0700 Subject: OpenDNS CGNAT Issues In-Reply-To: <16875.1536768672@turing-police.cc.vt.edu> References: <16875.1536768672@turing-police.cc.vt.edu> Message-ID: <8B9698A3-DCB2-434E-93A5-7E88913B933E@delong.com> If you do it for a mere footlocker, I will be happy to watch and laugh. Owen > On Sep 12, 2018, at 9:11 AM, valdis.kletnieks at vt.edu wrote: > > On Wed, 12 Sep 2018 14:10:05 -0000, Kenny Taylor said: > >> For a truckload of gold, I’m pretty sure most of us would make that work ☺ > > Unless they get underbid by the one of us willing to settle for a foot locker full of gold. > From amitchell at isipp.com Wed Sep 12 16:45:29 2018 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Wed, 12 Sep 2018 10:45:29 -0600 Subject: QWEST you have broken DNS servers In-Reply-To: <0777B4F2-E71F-467A-9A55-351DEFDA2526@isc.org> References: <0777B4F2-E71F-467A-9A55-351DEFDA2526@isc.org> Message-ID: Would you like us to send this to our Qwest/CenturyLink contact? 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 Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center Member, California Bar Association Member, Cal. Bar Cyberspace Law Committee Member, Colorado Cyber Committee Member, Board of Directors, Asilomar Microcomputer Workshop Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop > > I know it takes some time to upgrade DNS servers to ones that are actually > protocol compliant but 4+ years is ridiculous. Your servers are the only > ones serving the Alexa top 1M sites or the GOV zone that still return BADVERS > to EDNS queries with a EDNS option present. This was behaviour made up by > your DNS vendor. The correct response to EDNS options that are not understood > is to IGNORE them. This allows clients and servers to deploy support for > new options independently of each other. > > Additionally this is breaking DNSSEC validation of the signed zones your clients > have you serving. They expect you to be using EDNS compliant name servers for > this role which you are not. No, we are not working around this breakage in the > resolver. > > Mark > > % dig soa frc.gov. @208.44.130.121 +norec > > ; <<>> DiG 9.12.1 <<>> soa frc.gov. @208.44.130.121 +norec > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: BADVERS, id: 59707 > ;; flags: qr ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; Query time: 66 msec > ;; SERVER: 208.44.130.121#53(208.44.130.121) > ;; WHEN: Tue Sep 11 06:08:41 UTC 2018 > ;; MSG SIZE rcvd: 23 > > % dig soa frc.gov. @208.44.130.121 +norec +nocookie > > ; <<>> DiG 9.12.1 <<>> soa frc.gov. @208.44.130.121 +norec +nocookie > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16876 > ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;frc.gov. IN SOA > > ;; ANSWER SECTION: > frc.gov. 86400 IN SOA sauthns2.qwest.net. dns-admin.qwestip.net. 2180320527 10800 3600 604800 86400 > > ;; AUTHORITY SECTION: > frc.gov. 86400 IN NS sauthns1.qwest.net. > frc.gov. 86400 IN NS sauthns2.qwest.net. > > ;; Query time: 66 msec > ;; SERVER: 208.44.130.121#53(208.44.130.121) > ;; WHEN: Tue Sep 11 06:19:33 UTC 2018 > ;; MSG SIZE rcvd: 145 > > % grep ednsopt=badvers reports/alexa1m.2018-08-26T00:00:06Z | grep edns=ok | awk '{print $3}' | sort -u > (sauthns1.qwest.net.): > (sauthns2.qwest.net.): > % grep ednsopt=badvers reports-full/gov-full.2018-09-11T00:00:06Z | grep edns=ok | awk '{print $3}' | sort -u > (sauthns1.qwest.net.): > (sauthns2.qwest.net.): > % > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From denys at visp.net.lb Wed Sep 12 16:49:22 2018 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Wed, 12 Sep 2018 19:49:22 +0300 Subject: OpenDNS CGNAT Issues In-Reply-To: References: <40FBC3A3-FE91-4CFA-8DAE-314D05CEF942@rivervalleyinternet.net> Message-ID: <1668dfe8a5b642dbff284c23a9cd440a@visp.net.lb> On 2018-09-12 19:40, Lee Howard wrote: > On 09/11/2018 09:31 AM, Matt Hoppes wrote: >> So don't CGNat?  Buy IPv4 addresses at auction? > > Buy IPv4 addresses until CGN is cheaper. If a customer has to call, > and you have to assign an IPv4 address, you have to recover the cost > of that call and address. > While ((CostOfCall + CostOfAddress)*NumberOfCalls) > > (CostOfAddress*NumberOfNewCustomers): >      BuyAddresses(NumberOfNewCustomers) > > Meanwhile, deploy IPv6, and move toward IPv4aaS, probably 464xlat or > MAP, but your religion may vary. That way your "CGN" is an IPv6-IPv4 > translator, and that's easier than managing dual-stack. > > At the very least, dual-stack your web sites now, so the rest of us > can get to it without translation. > Just regarding ipv4 issue solution, this process can be somehow automated by detecting those who use opendns(by netflow, for example), to avoid "CostOfCall" part. Also, to avoid false claiming of nat pool, he can nat DNS requests for OpenDNS to different ip pool, that cannot be claimed. From valdis.kletnieks at vt.edu Wed Sep 12 17:33:05 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 12 Sep 2018 13:33:05 -0400 Subject: OpenDNS CGNAT Issues In-Reply-To: <8B9698A3-DCB2-434E-93A5-7E88913B933E@delong.com> References: <16875.1536768672@turing-police.cc.vt.edu> <8B9698A3-DCB2-434E-93A5-7E88913B933E@delong.com> Message-ID: <28821.1536773585@turing-police.cc.vt.edu> On Wed, 12 Sep 2018 09:42:11 -0700, Owen DeLong said: > If you do it for a mere footlocker, I will be happy to watch and laugh. So.. taking this as a size: https://www.containerstore.com/s/storage/trunks/black-rolling-trunk-with-tray/12d?productId=10000230 We'll shave off an inch or so off each dimension to get inside dimension. 30 x 16 x 15 is 7200 cubic inches. Gold is 11.1 ounces per cubic inch. (Oh, you'll need to get a special cart for that foot locker, I'm pretty sure the provided wheels won't support the 4,995 pounds of gold...) (Divide by 1.09 to convert to troy ounces) Gold is sitting at US$1,198.15 per troy ounce today. US$87,849,677.06 Still laughing? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From marka at isc.org Wed Sep 12 22:13:32 2018 From: marka at isc.org (Mark Andrews) Date: Thu, 13 Sep 2018 08:13:32 +1000 Subject: QWEST you have broken DNS servers In-Reply-To: References: <0777B4F2-E71F-467A-9A55-351DEFDA2526@isc.org> Message-ID: Yes please. > On 13 Sep 2018, at 2:45 am, Anne P. Mitchell, Esq. wrote: > > > Would you like us to send this to our Qwest/CenturyLink contact? > > 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 > Legal Counsel: The CyberGreen Institute > Legal Counsel: The Earth Law Center > Member, California Bar Association > Member, Cal. Bar Cyberspace Law Committee > Member, Colorado Cyber Committee > Member, Board of Directors, Asilomar Microcomputer Workshop > Ret. Professor of Law, Lincoln Law School of San Jose > Ret. Chair, Asilomar Microcomputer Workshop > > > >> >> I know it takes some time to upgrade DNS servers to ones that are actually >> protocol compliant but 4+ years is ridiculous. Your servers are the only >> ones serving the Alexa top 1M sites or the GOV zone that still return BADVERS >> to EDNS queries with a EDNS option present. This was behaviour made up by >> your DNS vendor. The correct response to EDNS options that are not understood >> is to IGNORE them. This allows clients and servers to deploy support for >> new options independently of each other. >> >> Additionally this is breaking DNSSEC validation of the signed zones your clients >> have you serving. They expect you to be using EDNS compliant name servers for >> this role which you are not. No, we are not working around this breakage in the >> resolver. >> >> Mark >> >> % dig soa frc.gov. @208.44.130.121 +norec >> >> ; <<>> DiG 9.12.1 <<>> soa frc.gov. @208.44.130.121 +norec >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: BADVERS, id: 59707 >> ;; flags: qr ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ;; Query time: 66 msec >> ;; SERVER: 208.44.130.121#53(208.44.130.121) >> ;; WHEN: Tue Sep 11 06:08:41 UTC 2018 >> ;; MSG SIZE rcvd: 23 >> >> % dig soa frc.gov. @208.44.130.121 +norec +nocookie >> >> ; <<>> DiG 9.12.1 <<>> soa frc.gov. @208.44.130.121 +norec +nocookie >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16876 >> ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ;; QUESTION SECTION: >> ;frc.gov. IN SOA >> >> ;; ANSWER SECTION: >> frc.gov. 86400 IN SOA sauthns2.qwest.net. dns-admin.qwestip.net. 2180320527 10800 3600 604800 86400 >> >> ;; AUTHORITY SECTION: >> frc.gov. 86400 IN NS sauthns1.qwest.net. >> frc.gov. 86400 IN NS sauthns2.qwest.net. >> >> ;; Query time: 66 msec >> ;; SERVER: 208.44.130.121#53(208.44.130.121) >> ;; WHEN: Tue Sep 11 06:19:33 UTC 2018 >> ;; MSG SIZE rcvd: 145 >> >> % grep ednsopt=badvers reports/alexa1m.2018-08-26T00:00:06Z | grep edns=ok | awk '{print $3}' | sort -u >> (sauthns1.qwest.net.): >> (sauthns2.qwest.net.): >> % grep ednsopt=badvers reports-full/gov-full.2018-09-11T00:00:06Z | grep edns=ok | awk '{print $3}' | sort -u >> (sauthns1.qwest.net.): >> (sauthns2.qwest.net.): >> % >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org >> > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mark.tinka at seacom.mu Thu Sep 13 05:53:04 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 13 Sep 2018 07:53:04 +0200 Subject: SAFNOG-4/EANOG/tzNOG - Just Under 2 Weeks To Go! Message-ID: Hi all. This is just a reminder that with a little under 2 weeks to go the upcoming SAFNOG-4/EANOG/tzNOG meeting to be held in Dar Es Salaam, 24th - 29th September, please remember to register your attendance at http://www.safnog.org/ so you don't miss the meeting. The agenda is now up on the web site at http://www.safnog.org/#agenda with just a few slots left which are filling fast. In case you feel like you have an interesting technical and operational talk that you'd like to share with the community at this meeting, please feel free to submit it for the program committee to review as soon as possible, at:     https://papers.safnog.org/user/login.php?event=76 Key talks that you would be looking forward include: * Ben Roberts (Liquid Telecom), talking about the latency realities of intra-African Internet communication. * The 3 major data centre projects that are happening in South Africa, Kenya and Uganda. * The DNSSEC key rollover due on 11th October, and what to look forward to, as explained by Amreesh Phokeer. * An IPv6 Deployathon 2-day workshop headed by Mukom Akong Tamon. * ... and so many more. There will be 2 social events where delegates can network, share a drink, some good food, and stand a chance to win either an iPhone X or AppleTV 4K. We have secured a special discount rate at the hotel venue for all SAFNOG/EANOG/tzNOG participants. More details are available at http://www.safnog.org/#venue . We look forward to seeing you in Dar Es Salaam. Mark Tinka On Behalf of the SAFNOG-4/EANOG/tzNOG Organising Committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Thu Sep 13 20:27:21 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 13 Sep 2018 13:27:21 -0700 Subject: Puerto Rico Internet Exchange In-Reply-To: References: Message-ID: It has been little over a year and we have been working on launching an internet exchange in puerto rico but of course hurricane and other things got in the way of achieving this. We now have identified what we believe the right location (most of the isp’s have presence in this location) backbone/ip transit connectivity, local team to provide onsite support. Having said that We have been engaged with several content delivery networks, OTTs but general feedback was that Puerto Rico was not on their radar for 2018 hence delayed launch. Now we are talking to same players about 2019 but general answer seemed like people were satisfied enough to serve Puerto Rico from Miami. Perhaps we are talking to really big CDNs, OTTs and we should engage differently however the level of interest is very low and I really don’t want to “build and they will come” again ;-) Bottom line is, if there was an IXP in Puerto Rico similar to ones in Florida, I am trying to understand who would actually deploy (just speak to your company only please) because most of my assumptions were proven wrong ;-) I guess I want to ask two questions, given its location in caribbean, does Puerto Rico need an internet exchange point? Would you join it?(it will be a membership based IXP where members share cost) Mehmet On Sat, Aug 12, 2017 at 4:27 AM Mehmet Akcin wrote: > Hey there! > > ... ok this time I am not going to call it PRIX ;) well name doesn't > matter really. Nearly 13 years ago I have attempted to start Puerto rico > Internet exchange in San Juan. I have lived there over 5 years and i just > wanted to really watch videos faster. The project somewhat died when i > moved to LA but now there are few interested party to start an internet > exchange in Puerto rico. The jsland historically had one of the slowest > broadband/internet services which seemed to have improved in recent years > however as of 2017 there still is not an IX in Puerto rico. > > We , 3-4 internet engineers (on island and remote) , want to look into > relaunch of this IX and hopefully find a way to keep local traffic > exchanged at high speeds and low cost. We need expertise, and people who > want to help any way they can. > > We are trying to make this IX a not-for-profit one and we are looking at > opeeating models to adapt which has worked incredibly well like Seattle IX. > > We are hoping the relaunch to happen sometime in 2018. Thanks in advance > hope to share more info and traffic data sometime , soon. Watch this space! > > Mehmet > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From James at arenalgroup.co Thu Sep 13 21:15:19 2018 From: James at arenalgroup.co (James Breeden) Date: Thu, 13 Sep 2018 21:15:19 +0000 Subject: Puerto Rico Internet Exchange In-Reply-To: References: Message-ID: Mehmet, My opinion to you (and I have no network in the Carribbean or interest in it other than a purely academic and technical exercise) would be that you guys go ahead and start, even if you just initially split the cost of the switch and interfaces to peer among yourselves. Once you get a base established of a lot of routes available, it may give you better “clout” for getting some larger players to connect to your IX or at least help sponsor an extension over transport to a Miami reach? Just thinking aloud. James W. Breeden Managing Partner [logo_transparent_background] Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media PO Box 1063 | Smithville, TX 78957 Email: james at arenalgroup.co | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co From: NANOG On Behalf Of Mehmet Akcin Sent: Thursday, September 13, 2018 3:27 PM To: nanog Subject: Re: Puerto Rico Internet Exchange It has been little over a year and we have been working on launching an internet exchange in puerto rico but of course hurricane and other things got in the way of achieving this. We now have identified what we believe the right location (most of the isp’s have presence in this location) backbone/ip transit connectivity, local team to provide onsite support. Having said that We have been engaged with several content delivery networks, OTTs but general feedback was that Puerto Rico was not on their radar for 2018 hence delayed launch. Now we are talking to same players about 2019 but general answer seemed like people were satisfied enough to serve Puerto Rico from Miami. Perhaps we are talking to really big CDNs, OTTs and we should engage differently however the level of interest is very low and I really don’t want to “build and they will come” again ;-) Bottom line is, if there was an IXP in Puerto Rico similar to ones in Florida, I am trying to understand who would actually deploy (just speak to your company only please) because most of my assumptions were proven wrong ;-) I guess I want to ask two questions, given its location in caribbean, does Puerto Rico need an internet exchange point? Would you join it?(it will be a membership based IXP where members share cost) Mehmet On Sat, Aug 12, 2017 at 4:27 AM Mehmet Akcin > wrote: Hey there! ... ok this time I am not going to call it PRIX ;) well name doesn't matter really. Nearly 13 years ago I have attempted to start Puerto rico Internet exchange in San Juan. I have lived there over 5 years and i just wanted to really watch videos faster. The project somewhat died when i moved to LA but now there are few interested party to start an internet exchange in Puerto rico. The jsland historically had one of the slowest broadband/internet services which seemed to have improved in recent years however as of 2017 there still is not an IX in Puerto rico. We , 3-4 internet engineers (on island and remote) , want to look into relaunch of this IX and hopefully find a way to keep local traffic exchanged at high speeds and low cost. We need expertise, and people who want to help any way they can. We are trying to make this IX a not-for-profit one and we are looking at opeeating models to adapt which has worked incredibly well like Seattle IX. We are hoping the relaunch to happen sometime in 2018. Thanks in advance hope to share more info and traffic data sometime , soon. Watch this space! Mehmet -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From joelja at bogus.com Thu Sep 13 21:29:55 2018 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 13 Sep 2018 14:29:55 -0700 Subject: Puerto Rico Internet Exchange In-Reply-To: References: Message-ID: <69AA6EF4-D50B-43D3-8767-DD5E73E1D971@bogus.com> > On Sep 13, 2018, at 1:27 PM, Mehmet Akcin wrote: > > It has been little over a year and we have been working on launching an internet exchange in puerto rico but of course hurricane and other things got in the way of achieving this. > > We now have identified what we believe the right location (most of the isp’s have presence in this location) backbone/ip transit connectivity, local team to provide onsite support. > > Having said that We have been engaged with several content delivery networks, OTTs but general feedback was that Puerto Rico was not on their radar for 2018 hence delayed launch. Now we are talking to same players about 2019 but general answer seemed like people were satisfied enough to serve Puerto Rico from Miami. > > Perhaps we are talking to really big CDNs, OTTs and we should engage differently however the level of interest is very low and I really don’t want to “build and they will come” again ;-) > > Bottom line is, if there was an IXP in Puerto Rico similar to ones in Florida, I am trying to understand who would actually deploy (just speak to your company only please) because most of my assumptions were proven wrong ;-) > > I guess I want to ask two questions, given its location in caribbean, does Puerto Rico need an internet exchange point? Would you join it?(it will be a membership based IXP where members share cost) Looking at it in my mind, the decision point is really about how much traffic can be served by being there. It took a long time to recover to pre-hurricane levels. I would hope in the longer term that it’s a growth story and makes that more compelling, actually having a destination to put equipment in and reach peers helps of course. Having any anycast service, to me it looks like Puerto Rico has significant connectivity landing places other than Miami. Most likely due to America Movil MAC and PCCS or other landings in the US/BVI. We we see Puerto Rican networks reach us in Atlanta, DC area and even New York. > > Mehmet > > On Sat, Aug 12, 2017 at 4:27 AM Mehmet Akcin > wrote: > Hey there! > > ... ok this time I am not going to call it PRIX ;) well name doesn't matter really. Nearly 13 years ago I have attempted to start Puerto rico Internet exchange in San Juan. I have lived there over 5 years and i just wanted to really watch videos faster. The project somewhat died when i moved to LA but now there are few interested party to start an internet exchange in Puerto rico. The jsland historically had one of the slowest broadband/internet services which seemed to have improved in recent years however as of 2017 there still is not an IX in Puerto rico. > > We , 3-4 internet engineers (on island and remote) , want to look into relaunch of this IX and hopefully find a way to keep local traffic exchanged at high speeds and low cost. We need expertise, and people who want to help any way they can. > > We are trying to make this IX a not-for-profit one and we are looking at opeeating models to adapt which has worked incredibly well like Seattle IX. > > We are hoping the relaunch to happen sometime in 2018. Thanks in advance hope to share more info and traffic data sometime , soon. Watch this space! > > Mehmet > -- > Mehmet > +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: Message signed with OpenPGP URL: From mel at beckman.org Thu Sep 13 21:32:46 2018 From: mel at beckman.org (Mel Beckman) Date: Thu, 13 Sep 2018 21:32:46 +0000 Subject: Puerto Rico Internet Exchange In-Reply-To: References: Message-ID: <51FB6344-113D-4D78-BE7E-349BC41F5958@beckman.org> Mehmet, In general an IX only makes sense when there are local resources to exchange. It doesn’t seem like PR has a lot of, if any, content providers of its own, so most consumer content is coming from offshore anyway. Given modern DWDM fiber, backhauling all that content shouldn’t be an issue. I recall that in mid-2015 PR landed the "most advanced undersea fiber-optic cable in the Caribbean and Central America”, uniting a total of seven countries and territories. The head end was at Telephonica’s data center. I remember in your Nanog talk ten years ago that you felt that peer-to-peer file sharing and VoIP were major bandwidth consumers, but I’ve never seen the actual statistics for that. But even if that’s the case, the small number of ISPs should be able to form and fund their own IX given a business need. I’ve done work in the Dominican Republic, and they’re in a similar situation, with no real business interest in an IX. You asked a pointed question: given its location, is an IX in PR necessary? I know you’re invested a ton of time and effort in making a PR exchange work, but I think you may already have the answer, given the low interest. That answer seems to be “no”. Of course, if you can get some major content provider buy-n, that might make the business case more solid. -mel On Sep 13, 2018, at 1:27 PM, Mehmet Akcin > wrote: It has been little over a year and we have been working on launching an internet exchange in puerto rico but of course hurricane and other things got in the way of achieving this. We now have identified what we believe the right location (most of the isp’s have presence in this location) backbone/ip transit connectivity, local team to provide onsite support. Having said that We have been engaged with several content delivery networks, OTTs but general feedback was that Puerto Rico was not on their radar for 2018 hence delayed launch. Now we are talking to same players about 2019 but general answer seemed like people were satisfied enough to serve Puerto Rico from Miami. Perhaps we are talking to really big CDNs, OTTs and we should engage differently however the level of interest is very low and I really don’t want to “build and they will come” again ;-) Bottom line is, if there was an IXP in Puerto Rico similar to ones in Florida, I am trying to understand who would actually deploy (just speak to your company only please) because most of my assumptions were proven wrong ;-) I guess I want to ask two questions, given its location in caribbean, does Puerto Rico need an internet exchange point? Would you join it?(it will be a membership based IXP where members share cost) Mehmet On Sat, Aug 12, 2017 at 4:27 AM Mehmet Akcin > wrote: Hey there! ... ok this time I am not going to call it PRIX ;) well name doesn't matter really. Nearly 13 years ago I have attempted to start Puerto rico Internet exchange in San Juan. I have lived there over 5 years and i just wanted to really watch videos faster. The project somewhat died when i moved to LA but now there are few interested party to start an internet exchange in Puerto rico. The jsland historically had one of the slowest broadband/internet services which seemed to have improved in recent years however as of 2017 there still is not an IX in Puerto rico. We , 3-4 internet engineers (on island and remote) , want to look into relaunch of this IX and hopefully find a way to keep local traffic exchanged at high speeds and low cost. We need expertise, and people who want to help any way they can. We are trying to make this IX a not-for-profit one and we are looking at opeeating models to adapt which has worked incredibly well like Seattle IX. We are hoping the relaunch to happen sometime in 2018. Thanks in advance hope to share more info and traffic data sometime , soon. Watch this space! Mehmet -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at 6by7.net Thu Sep 13 21:38:11 2018 From: ben at 6by7.net (Ben Cannon) Date: Thu, 13 Sep 2018 14:38:11 -0700 Subject: Puerto Rico Internet Exchange In-Reply-To: <51FB6344-113D-4D78-BE7E-349BC41F5958@beckman.org> References: <51FB6344-113D-4D78-BE7E-349BC41F5958@beckman.org> Message-ID: <68D2B3FB-A7B7-4684-8D3A-2886A176C4D6@6by7.net> Our SF2 facility’s IXP has a Netflix OpenFiler; https://openconnect.netflix.com That alone might be worth an XC/IXP. Even where bandwidth is available, it can still be prohibitively expensive - conversely lowering costs could translate to lowered fees to customers. -Ben. > On Sep 13, 2018, at 2:32 PM, Mel Beckman wrote: > > Mehmet, > > In general an IX only makes sense when there are local resources to exchange. It doesn’t seem like PR has a lot of, if any, content providers of its own, so most consumer content is coming from offshore anyway. Given modern DWDM fiber, backhauling all that content shouldn’t be an issue. I recall that in mid-2015 PR landed the "most advanced undersea fiber-optic cable in the Caribbean and Central America”, uniting a total of seven countries and territories. The head end was at Telephonica’s data center. I remember in your Nanog talk ten years ago that you felt that peer-to-peer file sharing and VoIP were major bandwidth consumers, but I’ve never seen the actual statistics for that. But even if that’s the case, the small number of ISPs should be able to form and fund their own IX given a business need. > > I’ve done work in the Dominican Republic, and they’re in a similar situation, with no real business interest in an IX. > > You asked a pointed question: given its location, is an IX in PR necessary? I know you’re invested a ton of time and effort in making a PR exchange work, but I think you may already have the answer, given the low interest. That answer seems to be “no”. > > Of course, if you can get some major content provider buy-n, that might make the business case more solid. > > -mel > > >> On Sep 13, 2018, at 1:27 PM, Mehmet Akcin > wrote: >> >> It has been little over a year and we have been working on launching an internet exchange in puerto rico but of course hurricane and other things got in the way of achieving this. >> >> We now have identified what we believe the right location (most of the isp’s have presence in this location) backbone/ip transit connectivity, local team to provide onsite support. >> >> Having said that We have been engaged with several content delivery networks, OTTs but general feedback was that Puerto Rico was not on their radar for 2018 hence delayed launch. Now we are talking to same players about 2019 but general answer seemed like people were satisfied enough to serve Puerto Rico from Miami. >> >> Perhaps we are talking to really big CDNs, OTTs and we should engage differently however the level of interest is very low and I really don’t want to “build and they will come” again ;-) >> >> Bottom line is, if there was an IXP in Puerto Rico similar to ones in Florida, I am trying to understand who would actually deploy (just speak to your company only please) because most of my assumptions were proven wrong ;-) >> >> I guess I want to ask two questions, given its location in caribbean, does Puerto Rico need an internet exchange point? Would you join it?(it will be a membership based IXP where members share cost) >> >> Mehmet >> >> On Sat, Aug 12, 2017 at 4:27 AM Mehmet Akcin > wrote: >> Hey there! >> >> ... ok this time I am not going to call it PRIX ;) well name doesn't matter really. Nearly 13 years ago I have attempted to start Puerto rico Internet exchange in San Juan. I have lived there over 5 years and i just wanted to really watch videos faster. The project somewhat died when i moved to LA but now there are few interested party to start an internet exchange in Puerto rico. The jsland historically had one of the slowest broadband/internet services which seemed to have improved in recent years however as of 2017 there still is not an IX in Puerto rico. >> >> We , 3-4 internet engineers (on island and remote) , want to look into relaunch of this IX and hopefully find a way to keep local traffic exchanged at high speeds and low cost. We need expertise, and people who want to help any way they can. >> >> We are trying to make this IX a not-for-profit one and we are looking at opeeating models to adapt which has worked incredibly well like Seattle IX. >> >> We are hoping the relaunch to happen sometime in 2018. Thanks in advance hope to share more info and traffic data sometime , soon. Watch this space! >> >> Mehmet >> -- >> Mehmet >> +1-424-298-1903 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Fri Sep 14 13:08:58 2018 From: sander at steffann.nl (Sander Steffann) Date: Fri, 14 Sep 2018 15:08:58 +0200 Subject: Puerto Rico Internet Exchange In-Reply-To: <51FB6344-113D-4D78-BE7E-349BC41F5958@beckman.org> References: <51FB6344-113D-4D78-BE7E-349BC41F5958@beckman.org> Message-ID: Hi, > In general an IX only makes sense when there are local resources to exchange. It doesn’t seem like PR has a lot of, if any, content providers of its own, so most consumer content is coming from offshore anyway. This can also work the other way: once there is a local IXP, it can open opportunities for local content providers. Cheers, Sander From mel at beckman.org Fri Sep 14 13:56:24 2018 From: mel at beckman.org (Mel Beckman) Date: Fri, 14 Sep 2018 13:56:24 +0000 Subject: Puerto Rico Internet Exchange In-Reply-To: <1996087648.2263.1536930846098.JavaMail.mhammett@ThunderFuck> References: <51FB6344-113D-4D78-BE7E-349BC41F5958@beckman.org> , <1996087648.2263.1536930846098.JavaMail.mhammett@ThunderFuck> Message-ID: <1D973347-EE49-4331-8942-DE0E0FD8FA19@beckman.org> Mike, But why would you want, as a content provider, to have your content hosted on the island? Backhauling it over fiber is no big deal across the short distances involved. As far as I can tell, PR has a glut of ocean floor fiber capacity, just installed a couple years ago. We're not talking stock market trades here, where milliseconds matter. We're talking Netflix movie reruns, which could be easily delivered with seconds of latency. Those who hold to the "if you build it they will come" business model forget that that model was a fantasy in a movie. A movie currently being streamed to PR without difficulty :-) -mel via cell On Sep 14, 2018, at 6:14 AM, Mike Hammett > wrote: Agreed. Very chicken or the egg. Any recently formed IX is largely a conduit for big content to connect to local eyeballs. As some critical mass of eyeballs is achieved, local content is interested as are large networks like Hurricane Electric. In the case of PR, if there are no local content providers, an IX provides an avenue for one to form to connect to other operators on the island, avoiding underwater cables to the mainland. If I were a company in PR, I'd want my web site and other services hosted in PR, not Miami or Virginia. ----- 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: "Sander Steffann" > To: "Mel Beckman" > Cc: "nanog" > Sent: Friday, September 14, 2018 8:08:58 AM Subject: Re: Puerto Rico Internet Exchange Hi, > In general an IX only makes sense when there are local resources to exchange. It doesn’t seem like PR has a lot of, if any, content providers of its own, so most consumer content is coming from offshore anyway. This can also work the other way: once there is a local IXP, it can open opportunities for local content providers. Cheers, Sander -------------- next part -------------- An HTML attachment was scrubbed... URL: From darin.steffl at mnwifi.com Fri Sep 14 14:55:54 2018 From: darin.steffl at mnwifi.com (Darin Steffl) Date: Fri, 14 Sep 2018 09:55:54 -0500 Subject: Puerto Rico Internet Exchange In-Reply-To: <1D973347-EE49-4331-8942-DE0E0FD8FA19@beckman.org> References: <51FB6344-113D-4D78-BE7E-349BC41F5958@beckman.org> <1996087648.2263.1536930846098.JavaMail.mhammett@ThunderFuck> <1D973347-EE49-4331-8942-DE0E0FD8FA19@beckman.org> Message-ID: What is the average latency from the mainland to PR? If it's under 10ms, there's probably not a huge push for a local IX. But to compare to our IX in Minnesota, we are within 8ms of Chicago and we certainly didn't need one here but a group of guys got together some donations and donated rack space, power, etc. And now we have a very busy IX with most of the big players on it. I think we push almost 211 gbps at peak. So our model was a "build it and they will come" and it worked great. It's very popular and many content providers and ISP's are peered here including us. Our exchange has since started charging port fees but it was free to join for the longest time. http://micemn.net On Fri, Sep 14, 2018, 8:57 AM Mel Beckman wrote: > Mike, > > But why would you want, as a content provider, to have your content hosted > on the island? Backhauling it over fiber is no big deal across the short > distances involved. As far as I can tell, PR has a glut of ocean floor > fiber capacity, just installed a couple years ago. We're not talking stock > market trades here, where milliseconds matter. We're talking Netflix movie > reruns, which could be easily delivered with seconds of latency. > > Those who hold to the "if you build it they will come" business model > forget that that model was a fantasy in a movie. > > A movie currently being streamed to PR without difficulty :-) > > -mel via cell > > On Sep 14, 2018, at 6:14 AM, Mike Hammett wrote: > > Agreed. Very chicken or the egg. Any recently formed IX is largely a > conduit for big content to connect to local eyeballs. As some critical mass > of eyeballs is achieved, local content is interested as are large networks > like Hurricane Electric. > > In the case of PR, if there are no local content providers, an IX provides > an avenue for one to form to connect to other operators on the island, > avoiding underwater cables to the mainland. If I were a company in PR, I'd > want my web site and other services hosted in PR, not Miami or Virginia. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > ------------------------------ > *From: *"Sander Steffann" > *To: *"Mel Beckman" > *Cc: *"nanog" > *Sent: *Friday, September 14, 2018 8:08:58 AM > *Subject: *Re: Puerto Rico Internet Exchange > > Hi, > > > In general an IX only makes sense when there are local resources to > exchange. It doesn’t seem like PR has a lot of, if any, content providers > of its own, so most consumer content is coming from offshore anyway. > > This can also work the other way: once there is a local IXP, it can open > opportunities for local content providers. > > Cheers, > Sander > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valeriu at roedu.net Fri Sep 14 05:03:07 2018 From: valeriu at roedu.net (Valeriu Vraciu) Date: Fri, 14 Sep 2018 08:03:07 +0300 Subject: tier 4 datacenter requirement "translation" Message-ID: <21e715d2-b111-a718-7685-5f2b354b9941@roedu.net> Hello, It may be somehow offtopic, but maybe someone can help understand the meaning of a requirement for Tier 4 DC. We have a project to build a Tier 4 datacenter. One of the requirements specified in TIA942 and related to roof of the building sounds like this: "double redundant with concrete deck (no mechanically attached systems)" For my understanding (being not a native English speaker) what exactly does this mean ? 1. no mechanically attached to the roof systems (gear, equipment) like air-conditioning, generators etc. or 2. the roof (double) is made from components that are not mechanically attached with bolts and such. Thanks in advance. -- Valeriu Vraciu RoEduNet -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 873 bytes Desc: OpenPGP digital signature URL: From drew.weaver at thenap.com Fri Sep 14 15:06:13 2018 From: drew.weaver at thenap.com (Drew Weaver) Date: Fri, 14 Sep 2018 15:06:13 +0000 Subject: Database that netflix/hulu use to determine who is a proxy and who isnt? Message-ID: <5bf28cbacffe4f02916f28b33a71682b@EXCHANGE2K13.thenap.com> It seems like recently one of the sources for IP info that Netflix and Hulu uses was updated with erroneous information as access to both of the services was revoked pretty much at the same time. Does anyone know what source they use for that information so I can request that they fix some of their information? Thanks, -Drew -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at wi-fiber.io Fri Sep 14 15:17:13 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Fri, 14 Sep 2018 09:17:13 -0600 Subject: Database that netflix/hulu use to determine who is a proxy and who isnt? In-Reply-To: <5bf28cbacffe4f02916f28b33a71682b@EXCHANGE2K13.thenap.com> References: <5bf28cbacffe4f02916f28b33a71682b@EXCHANGE2K13.thenap.com> Message-ID: maxmind and the other geolocation databases have the biggest effect. if updating that doesn't fix your problem. Geosupport at netflix.com can get you squared away On Fri, Sep 14, 2018, 9:08 AM Drew Weaver wrote: > It seems like recently one of the sources for IP info that Netflix and > Hulu uses was updated with erroneous information as access to both of the > services was revoked pretty much at the same time. > > > > Does anyone know what source they use for that information so I can > request that they fix some of their information? > > > > Thanks, > > -Drew > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lathama at gmail.com Fri Sep 14 15:34:41 2018 From: lathama at gmail.com (Andrew Latham) Date: Fri, 14 Sep 2018 10:34:41 -0500 Subject: tier 4 datacenter requirement "translation" In-Reply-To: <21e715d2-b111-a718-7685-5f2b354b9941@roedu.net> References: <21e715d2-b111-a718-7685-5f2b354b9941@roedu.net> Message-ID: I would have to go check for sure but I believe it applies to screws or bolts that could pierce the membrane. A well sealed roof is all they are looking for. On Fri, Sep 14, 2018 at 10:03 AM Valeriu Vraciu wrote: > Hello, > > > It may be somehow offtopic, but maybe someone can help understand the > meaning of a requirement for Tier 4 DC. > > We have a project to build a Tier 4 datacenter. One of the requirements > specified in TIA942 and related to roof of the building sounds like this: > > "double redundant with concrete deck (no mechanically attached systems)" > > For my understanding (being not a native English speaker) what exactly > does this mean ? > 1. no mechanically attached to the roof systems (gear, equipment) like > air-conditioning, generators etc. > > or > > 2. the roof (double) is made from components that are not mechanically > attached with bolts and such. > > > Thanks in advance. > > > -- > Valeriu Vraciu > RoEduNet > > -- - Andrew "lathama" Latham - -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at mtin.net Fri Sep 14 16:31:29 2018 From: lists at mtin.net (Justin Wilson) Date: Fri, 14 Sep 2018 12:31:29 -0400 Subject: Google Captcha Message-ID: In the experience of the community what causes the “Unusual traffic” messages when doing google searches? This ISP network hands out public IP addresses to each and every customer. No batting going on. Does Google typically drop entire /24’s into this if they see an issue? The initial troubleshooting we have done involves disconnecting the customer router and going direct with a laptop. Still the same captcha. We clock “I am not a robot” and the search goes through, but it re-appaers the next search. Looking for a direction to look. What typically causes this? I know what the page says, but looking for specifics. Thanks Justin Wilson j2sw at mtin.net www.mtin.net www.midwest-ix.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From amitchell at isipp.com Fri Sep 14 17:42:48 2018 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Fri, 14 Sep 2018 11:42:48 -0600 Subject: QWEST you have broken DNS servers In-Reply-To: References: <0777B4F2-E71F-467A-9A55-351DEFDA2526@isc.org> Message-ID: From Qwest/CL: "we are aware of the issue and expect this to be resolved next month." > > Yes please. > >> On 13 Sep 2018, at 2:45 am, Anne P. Mitchell, Esq. wrote: >> >> >> Would you like us to send this to our Qwest/CenturyLink contact? >> >> 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 >> Legal Counsel: The CyberGreen Institute >> Legal Counsel: The Earth Law Center >> Member, California Bar Association >> Member, Cal. Bar Cyberspace Law Committee >> Member, Colorado Cyber Committee >> Member, Board of Directors, Asilomar Microcomputer Workshop >> Ret. Professor of Law, Lincoln Law School of San Jose >> Ret. Chair, Asilomar Microcomputer Workshop >> >> >> >>> >>> I know it takes some time to upgrade DNS servers to ones that are actually >>> protocol compliant but 4+ years is ridiculous. Your servers are the only >>> ones serving the Alexa top 1M sites or the GOV zone that still return BADVERS >>> to EDNS queries with a EDNS option present. This was behaviour made up by >>> your DNS vendor. The correct response to EDNS options that are not understood >>> is to IGNORE them. This allows clients and servers to deploy support for >>> new options independently of each other. >>> >>> Additionally this is breaking DNSSEC validation of the signed zones your clients >>> have you serving. They expect you to be using EDNS compliant name servers for >>> this role which you are not. No, we are not working around this breakage in the >>> resolver. >>> >>> Mark >>> >>> % dig soa frc.gov. @208.44.130.121 +norec >>> >>> ; <<>> DiG 9.12.1 <<>> soa frc.gov. @208.44.130.121 +norec >>> ;; global options: +cmd >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: BADVERS, id: 59707 >>> ;; flags: qr ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >>> >>> ;; OPT PSEUDOSECTION: >>> ; EDNS: version: 0, flags:; udp: 4096 >>> ;; Query time: 66 msec >>> ;; SERVER: 208.44.130.121#53(208.44.130.121) >>> ;; WHEN: Tue Sep 11 06:08:41 UTC 2018 >>> ;; MSG SIZE rcvd: 23 >>> >>> % dig soa frc.gov. @208.44.130.121 +norec +nocookie >>> >>> ; <<>> DiG 9.12.1 <<>> soa frc.gov. @208.44.130.121 +norec +nocookie >>> ;; global options: +cmd >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16876 >>> ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 >>> >>> ;; OPT PSEUDOSECTION: >>> ; EDNS: version: 0, flags:; udp: 4096 >>> ;; QUESTION SECTION: >>> ;frc.gov. IN SOA >>> >>> ;; ANSWER SECTION: >>> frc.gov. 86400 IN SOA sauthns2.qwest.net. dns-admin.qwestip.net. 2180320527 10800 3600 604800 86400 >>> >>> ;; AUTHORITY SECTION: >>> frc.gov. 86400 IN NS sauthns1.qwest.net. >>> frc.gov. 86400 IN NS sauthns2.qwest.net. >>> >>> ;; Query time: 66 msec >>> ;; SERVER: 208.44.130.121#53(208.44.130.121) >>> ;; WHEN: Tue Sep 11 06:19:33 UTC 2018 >>> ;; MSG SIZE rcvd: 145 >>> >>> % grep ednsopt=badvers reports/alexa1m.2018-08-26T00:00:06Z | grep edns=ok | awk '{print $3}' | sort -u >>> (sauthns1.qwest.net.): >>> (sauthns2.qwest.net.): >>> % grep ednsopt=badvers reports-full/gov-full.2018-09-11T00:00:06Z | grep edns=ok | awk '{print $3}' | sort -u >>> (sauthns1.qwest.net.): >>> (sauthns2.qwest.net.): >>> % >>> >>> -- >>> Mark Andrews, ISC >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org >>> >> >> > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From cscora at apnic.net Fri Sep 14 18:03:12 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 15 Sep 2018 04:03:12 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180914180312.413AEC450F@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 15 Sep, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 715632 Prefixes after maximum aggregation (per Origin AS): 274995 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 343809 Total ASes present in the Internet Routing Table: 61843 Prefixes per ASN: 11.57 Origin-only ASes present in the Internet Routing Table: 53396 Origin ASes announcing only one prefix: 23286 Transit ASes present in the Internet Routing Table: 8447 Transit-only ASes present in the Internet Routing Table: 259 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 36 Max AS path prepend of ASN ( 30873) 34 Prefixes from unregistered ASNs in the Routing Table: 69 Number of instances of unregistered ASNs: 69 Number of 32-bit ASNs allocated by the RIRs: 24086 Number of 32-bit ASNs visible in the Routing Table: 19447 Prefixes from 32-bit ASNs in the Routing Table: 81493 Number of bogon 32-bit ASNs visible in the Routing Table: 25 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 324 Number of addresses announced to Internet: 2853242180 Equivalent to 170 /8s, 17 /16s and 5 /24s Percentage of available address space announced: 77.1 Percentage of allocated address space announced: 77.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.0 Total number of prefixes smaller than registry allocations: 239222 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 195042 Total APNIC prefixes after maximum aggregation: 55503 APNIC Deaggregation factor: 3.51 Prefixes being announced from the APNIC address blocks: 193100 Unique aggregates announced from the APNIC address blocks: 79556 APNIC Region origin ASes present in the Internet Routing Table: 9093 APNIC Prefixes per ASN: 21.24 APNIC Region origin ASes announcing only one prefix: 2555 APNIC Region transit ASes present in the Internet Routing Table: 1365 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 31 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4053 Number of APNIC addresses announced to Internet: 768098051 Equivalent to 45 /8s, 200 /16s and 63 /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: 212696 Total ARIN prefixes after maximum aggregation: 100695 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 212454 Unique aggregates announced from the ARIN address blocks: 100997 ARIN Region origin ASes present in the Internet Routing Table: 18246 ARIN Prefixes per ASN: 11.64 ARIN Region origin ASes announcing only one prefix: 6772 ARIN Region transit ASes present in the Internet Routing Table: 1809 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2431 Number of ARIN addresses announced to Internet: 1097187744 Equivalent to 65 /8s, 101 /16s and 193 /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: 195831 Total RIPE prefixes after maximum aggregation: 93419 RIPE Deaggregation factor: 2.10 Prefixes being announced from the RIPE address blocks: 192076 Unique aggregates announced from the RIPE address blocks: 113790 RIPE Region origin ASes present in the Internet Routing Table: 25466 RIPE Prefixes per ASN: 7.54 RIPE Region origin ASes announcing only one prefix: 11474 RIPE Region transit ASes present in the Internet Routing Table: 3521 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 36 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7397 Number of RIPE addresses announced to Internet: 714375296 Equivalent to 42 /8s, 148 /16s and 128 /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: 92435 Total LACNIC prefixes after maximum aggregation: 21188 LACNIC Deaggregation factor: 4.36 Prefixes being announced from the LACNIC address blocks: 93843 Unique aggregates announced from the LACNIC address blocks: 41083 LACNIC Region origin ASes present in the Internet Routing Table: 7551 LACNIC Prefixes per ASN: 12.43 LACNIC Region origin ASes announcing only one prefix: 2079 LACNIC Region transit ASes present in the Internet Routing Table: 1421 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5095 Number of LACNIC addresses announced to Internet: 172151840 Equivalent to 10 /8s, 66 /16s and 212 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 19558 Total AfriNIC prefixes after maximum aggregation: 4129 AfriNIC Deaggregation factor: 4.74 Prefixes being announced from the AfriNIC address blocks: 23835 Unique aggregates announced from the AfriNIC address blocks: 8111 AfriNIC Region origin ASes present in the Internet Routing Table: 1201 AfriNIC Prefixes per ASN: 19.85 AfriNIC Region origin ASes announcing only one prefix: 406 AfriNIC Region transit ASes present in the Internet Routing Table: 240 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 26 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 471 Number of AfriNIC addresses announced to Internet: 100971520 Equivalent to 6 /8s, 4 /16s and 180 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 4632 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4435 483 475 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 2988 1154 90 VIETEL-AS-AP Viettel Group, VN 9829 2811 1495 540 BSNL-NIB National Internet Backbone, IN 4766 2804 11135 772 KIXS-AS-KR Korea Telecom, KR 45899 2746 1658 158 VNPT-AS-VN VNPT Corp, VN 9394 2610 4907 31 CTTNET China TieTong Telecommunications 9808 2264 8699 26 CMNET-GD Guangdong Mobile Communication 17974 2256 962 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4755 2121 417 204 TATACOMM-AS TATA Communications formerl Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6327 3467 1324 84 SHAW - Shaw Communications Inc., CA 11492 3404 236 494 CABLEONE - CABLE ONE, INC., US 22773 3237 2971 155 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2285 4938 793 AMAZON-02 - Amazon.com, Inc., US 18566 2165 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2157 2741 512 CHARTER-NET-HKY-NC - Charter Communicat 30036 2043 347 135 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 2040 5084 603 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16625 1980 1056 1472 AKAMAI-AS - Akamai Technologies, Inc., 5650 1887 3224 1320 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 4853 1616 127 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3062 378 44 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2567 618 1912 AKAMAI-ASN1, US 12389 2049 1919 729 ROSTELECOM-AS, RU 34984 2036 336 508 TELLCOM-AS, TR 9121 1866 1691 17 TTNET, TR 13188 1604 100 43 TRIOLAN, UA 8402 1255 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1241 355 21 UKRTELNET, UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5275 3339 600 Uninet S.A. de C.V., MX 10620 3221 493 777 Telmex Colombia S.A., CO 11830 2654 370 81 Instituto Costarricense de Electricidad 6503 1654 444 66 Axtel, S.A.B. de C.V., MX 7303 1431 954 205 Telecom Argentina S.A., AR 28573 1094 2231 192 CLARO S.A., BR 3816 1016 509 121 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 937 377 31 Telefonica del Peru S.A.A., PE 11172 933 128 70 Alestra, S. de R.L. de C.V., MX 18881 917 1098 28 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1195 396 48 LINKdotNET-AS, EG 37611 901 107 9 Afrihost, ZA 36903 778 391 137 MT-MPLS, MA 36992 750 1411 41 ETISALAT-MISR, EG 24835 643 818 18 RAYA-AS, EG 8452 602 1728 14 TE-AS TE-AS, EG 37492 473 470 57 ORANGE-, TN 29571 463 70 11 ORANGE-COTE-IVOIRE, CI 37342 386 32 1 MOVITEL, MZ 23889 376 231 15 MauritiusTelecom, MU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5275 3339 600 Uninet S.A. de C.V., MX 12479 4853 1616 127 UNI2-AS, ES 4538 4632 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4435 483 475 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 6327 3467 1324 84 SHAW - Shaw Communications Inc., CA 11492 3404 236 494 CABLEONE - CABLE ONE, INC., US 22773 3237 2971 155 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3221 493 777 Telmex Colombia S.A., CO 8551 3062 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 4853 4726 UNI2-AS, ES 4538 4632 4558 ERX-CERNET-BKB China Education and Research Net 7545 4435 3960 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3467 3383 SHAW - Shaw Communications Inc., CA 22773 3237 3082 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3062 3018 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 3404 2910 CABLEONE - CABLE ONE, INC., US 7552 2988 2898 VIETEL-AS-AP Viettel Group, VN 45899 2746 2588 VNPT-AS-VN VNPT Corp, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 4200003000 PRIVATE 47.89.98.0/24 45102 CNNIC-ALIBABA-CN-NET-AP Alibab 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 64121 UNALLOCATED 98.159.9.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64121 UNALLOCATED 98.159.12.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64140 UNALLOCATED 98.159.14.0/24 64121 UNKNOWN Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.136.0/24 37500 -Reserved AS-, ZZ 41.76.138.0/24 37500 -Reserved AS-, ZZ 41.76.139.0/24 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/24 37500 -Reserved AS-, ZZ 41.76.141.0/24 37500 -Reserved AS-, ZZ 41.76.142.0/24 37500 -Reserved AS-, ZZ 41.76.143.0/24 37500 -Reserved AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:14 /9:11 /10:36 /11:98 /12:289 /13:564 /14:1097 /15:1889 /16:13340 /17:7916 /18:13812 /19:25359 /20:39533 /21:45768 /22:88785 /23:72679 /24:402263 /25:802 /26:612 /27:633 /28:36 /29:21 /30:19 /31:4 /32:52 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 3602 4853 UNI2-AS, ES 6327 3255 3467 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2714 3404 CABLEONE - CABLE ONE, INC., US 8551 2524 3062 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2501 3237 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2059 2165 MEGAPATH5-US - MegaPath Corporation, US 11830 2004 2654 Instituto Costarricense de Electricidad y Telec 30036 1791 2043 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1554 1887 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:1594 2:844 4:18 5:2817 6:44 7:1 8:1134 12:1868 13:211 14:1813 15:34 16:3 17:196 18:55 20:50 23:2450 24:2357 25:2 27:2481 31:1978 32:88 35:29 36:535 37:2841 38:1533 39:261 40:112 41:3234 42:708 43:1940 44:115 45:5481 46:3116 47:211 49:1347 50:1053 51:318 52:1087 54:367 55:1 56:8 57:38 58:1622 59:992 60:410 61:2114 62:1899 63:1799 64:5050 65:2219 66:4698 67:2652 68:1153 69:3366 70:1157 71:576 72:2218 74:2727 75:417 76:457 77:1635 78:1715 79:2237 80:1572 81:1398 82:1061 83:787 84:1038 85:2015 86:569 87:1419 88:926 89:2343 90:211 91:6433 92:1263 93:2384 94:2449 95:3002 96:933 97:355 98:928 99:138 100:86 101:1189 102:203 103:18653 104:3533 105:218 106:762 107:1797 108:709 109:3323 110:1647 111:1793 112:1342 113:1305 114:1143 115:1674 116:1657 117:1777 118:2206 119:1662 120:1042 121:1046 122:2424 123:1645 124:1420 125:1927 128:1122 129:677 130:492 131:1622 132:728 133:191 134:1030 135:236 136:502 137:654 138:1941 139:680 140:484 141:746 142:842 143:1034 144:819 145:481 146:1249 147:740 148:1670 149:769 150:761 151:1099 152:841 153:324 154:1703 155:804 156:1447 157:804 158:660 159:1849 160:1389 161:830 162:2662 163:607 164:1084 165:1551 166:454 167:1215 168:3211 169:846 170:3988 171:494 172:1003 173:2098 174:992 175:803 176:2077 177:3924 178:2519 179:1259 180:2183 181:2417 182:2579 183:1253 184:1078 185:14086 186:3555 187:2502 188:2898 189:1999 190:8207 191:1386 192:9832 193:6163 194:5032 195:4001 196:2728 197:1606 198:5596 199:5948 200:7332 201:4973 202:10240 203:10288 204:4589 205:2872 206:3224 207:3195 208:3921 209:4085 210:3892 211:1998 212:3022 213:2821 214:1047 215:54 216:6025 217:2128 218:866 219:566 220:1797 221:999 222:988 223:1392 End of report From dmburgess at linktechs.net Fri Sep 14 18:10:42 2018 From: dmburgess at linktechs.net (Dennis Burgess) Date: Fri, 14 Sep 2018 18:10:42 +0000 Subject: Playstation/Sony Support Message-ID: <1fdd77f20ca84c508424e99f0ffeb92c@linktechs.net> I am looking for someone that can help me with a IP that appears banned from the PS4 network. If you are around, please hit me off-list :) Thanx, Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition" Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net Create Wireless Coverage's with www.towercoverage.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at 6by7.net Fri Sep 14 19:53:29 2018 From: ben at 6by7.net (Ben Cannon) Date: Fri, 14 Sep 2018 12:53:29 -0700 Subject: tier 4 datacenter requirement "translation" In-Reply-To: References: <21e715d2-b111-a718-7685-5f2b354b9941@roedu.net> Message-ID: Datacenter owner/operator and retired engineering contractor here. They are not talking about “mechanical” systems such as HVAC, they are instead describing a “Mechanically attached roofing system”. That’s a specific term, and covers metal roofs of a specific type and construction. See: https://msrs.com/new-construction/fully-adhered-vs-mechanically-attached/ Concrete is a superior substitute. Concrete deck your datacenter and you’re done. It’s considered pretty bulletproof. Figuratively and literally. Our DCs have concrete floors walls and ceilings. -Ben > On Sep 14, 2018, at 8:34 AM, Andrew Latham wrote: > > I would have to go check for sure but I believe it applies to screws or bolts that could pierce the membrane. A well sealed roof is all they are looking for. > >> On Fri, Sep 14, 2018 at 10:03 AM Valeriu Vraciu wrote: >> Hello, >> >> >> It may be somehow offtopic, but maybe someone can help understand the >> meaning of a requirement for Tier 4 DC. >> >> We have a project to build a Tier 4 datacenter. One of the requirements >> specified in TIA942 and related to roof of the building sounds like this: >> >> "double redundant with concrete deck (no mechanically attached systems)" >> >> For my understanding (being not a native English speaker) what exactly >> does this mean ? >> 1. no mechanically attached to the roof systems (gear, equipment) like >> air-conditioning, generators etc. >> >> or >> >> 2. the roof (double) is made from components that are not mechanically >> attached with bolts and such. >> >> >> Thanks in advance. >> >> >> -- >> Valeriu Vraciu >> RoEduNet >> > > > -- > - Andrew "lathama" Latham - -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Fri Sep 14 21:10:25 2018 From: ross at tajvar.io (Ross Tajvar) Date: Fri, 14 Sep 2018 17:10:25 -0400 Subject: Google Captcha In-Reply-To: References: Message-ID: As I understand it, no one really knows. They refuse to tell anyone. On Fri, Sep 14, 2018 at 12:31 PM, Justin Wilson wrote: > In the experience of the community what causes the “Unusual traffic” > messages when doing google searches? This ISP network hands out public IP > addresses to each and every customer. No batting going on. Does Google > typically drop entire /24’s into this if they see an issue? The initial > troubleshooting we have done involves disconnecting the customer router and > going direct with a laptop. Still the same captcha. We clock “I am not a > robot” and the search goes through, but it re-appaers the next search. > > Looking for a direction to look. What typically causes this? I know what > the page says, but looking for specifics. > > Thanks > > > Justin Wilson > j2sw at mtin.net > > www.mtin.net > www.midwest-ix.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From selphie.keller at gmail.com Fri Sep 14 21:18:34 2018 From: selphie.keller at gmail.com (Selphie Keller) Date: Fri, 14 Sep 2018 15:18:34 -0600 Subject: Google Captcha In-Reply-To: References: Message-ID: Yeah google captcha is fun, I trigger this all the time when relentlessly searching for something, ironically I giggle at the idea that my searching is so extreme it's classified as a bot at times. On Fri, 14 Sep 2018 at 10:32, Justin Wilson wrote: > In the experience of the community what causes the “Unusual traffic” > messages when doing google searches? This ISP network hands out public IP > addresses to each and every customer. No batting going on. Does Google > typically drop entire /24’s into this if they see an issue? The initial > troubleshooting we have done involves disconnecting the customer router and > going direct with a laptop. Still the same captcha. We clock “I am not a > robot” and the search goes through, but it re-appaers the next search. > > Looking for a direction to look. What typically causes this? I know what > the page says, but looking for specifics. > > Thanks > > > Justin Wilson > j2sw at mtin.net > > www.mtin.net > www.midwest-ix.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nop at imap.cc Fri Sep 14 21:20:46 2018 From: nop at imap.cc (nop at imap.cc) Date: Fri, 14 Sep 2018 14:20:46 -0700 Subject: Google Captcha In-Reply-To: References: Message-ID: <1536960046.1418630.1508614744.37BAE921@webmail.messagingengine.com> - Not being signed in to a Google account with a verified phone number - Searching complex things that look like dorks ("powered by vbulletin", "xxx v0.0.1", etc), can trigger within a page or two sometimes - Does this end user lease any IPs from brokers or otherwise? - on extremely, very, very dirty/dangerous/bad netblocks used almost entirely for fraud, bots, ddos, etc before (google Methbot; example of a few that almost certainly gets high risk penalized on everything: https://bgp.he.net/search?search%5Bsearch%5D=%22Cloud+innovation%22+or+%22cloudinnovation%22+or+%22larus%22+or+%22netstack%22+or+%22DET+Africa%22+or+%22Digital+Energy%22+or+%22GZ+Systems%22&commit=Search ) - Blocking cookies - Malware using you as a proxy is also a thing - a lot of the proxy sellers (google for backconnect, reverse backconnect, etc) entirely run off malware, botnet, etc. They are often used for checkout/stolen credit cards/"carding"/L7 http flooding services such as Shopify and Nike. This will result in extremely persistent "bans" from recaptcha because virtually all of these checkout sites utilise it On Fri, Sep 14, 2018, at 9:31 AM, Justin Wilson wrote: > In the experience of the community what causes the “Unusual traffic” > messages when doing google searches? This ISP network hands out public > IP addresses to each and every customer. No batting going on. Does > Google typically drop entire /24’s into this if they see an issue? > The initial troubleshooting we have done involves disconnecting the > customer router and going direct with a laptop. Still the same > captcha. We clock “I am not a robot” and the search goes through, but > it re-appaers the next search.> > Looking for a direction to look. What typically causes this? I know > what the page says, but looking for specifics.> > Thanks > > > Justin Wilson > j2sw at mtin.net > > www.mtin.net > www.midwest-ix.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From CGross at ninestarconnect.com Fri Sep 14 21:24:55 2018 From: CGross at ninestarconnect.com (Chris Gross) Date: Fri, 14 Sep 2018 21:24:55 +0000 Subject: Google Captcha In-Reply-To: References: , Message-ID: Im going with the corporate greed/free labor angle. Perhaps they need more training data for their cars and figure a couple small ISP/businesses worth of people is worth flipping over temporarily? This email has been sent from my phone. Please excuse any brevity, typos, or lack of formality. ________________________________ From: Selphie Keller Sent: Friday, September 14, 2018 17:20 To: lists at mtin.net Cc: NANOG list Subject: Re: Google Captcha Yeah google captcha is fun, I trigger this all the time when relentlessly searching for something, ironically I giggle at the idea that my searching is so extreme it's classified as a bot at times. On Fri, 14 Sep 2018 at 10:32, Justin Wilson > wrote: In the experience of the community what causes the “Unusual traffic” messages when doing google searches? This ISP network hands out public IP addresses to each and every customer. No batting going on. Does Google typically drop entire /24’s into this if they see an issue? The initial troubleshooting we have done involves disconnecting the customer router and going direct with a laptop. Still the same captcha. We clock “I am not a robot” and the search goes through, but it re-appaers the next search. Looking for a direction to look. What typically causes this? I know what the page says, but looking for specifics. Thanks Justin Wilson j2sw at mtin.net www.mtin.net www.midwest-ix.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From damian at google.com Fri Sep 14 21:44:49 2018 From: damian at google.com (Damian Menscher) Date: Fri, 14 Sep 2018 14:44:49 -0700 Subject: Google Captcha In-Reply-To: References: Message-ID: Solving a captcha issues an exemption cookie. If you're being blocked again on the "next search" this implies that cookie isn't working because: - your "next search" was several hours later, and the exemption cookie expired - you cleared cookies (or used a different browser) - you're doing something abusive from that browser that gets your exemption cookie blocked Damian On Fri, Sep 14, 2018 at 9:32 AM Justin Wilson wrote: > In the experience of the community what causes the “Unusual traffic” > messages when doing google searches? This ISP network hands out public IP > addresses to each and every customer. No batting going on. Does Google > typically drop entire /24’s into this if they see an issue? The initial > troubleshooting we have done involves disconnecting the customer router and > going direct with a laptop. Still the same captcha. We clock “I am not a > robot” and the search goes through, but it re-appaers the next search. > > Looking for a direction to look. What typically causes this? I know what > the page says, but looking for specifics. > > Thanks > > > Justin Wilson > j2sw at mtin.net > > www.mtin.net > www.midwest-ix.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Fri Sep 14 22:39:41 2018 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 14 Sep 2018 15:39:41 -0700 Subject: Playstation/Sony Support In-Reply-To: <1fdd77f20ca84c508424e99f0ffeb92c@linktechs.net> References: <1fdd77f20ca84c508424e99f0ffeb92c@linktechs.net> Message-ID: Every IP of mine that's banned is banned because of a hacked Mikrotik router. Despite keeping up with the numerous updates, it seems almost every one I own got hit in the last week. Matthew Kaufman On Fri, Sep 14, 2018 at 11:13 AM Dennis Burgess via NANOG wrote: > I am looking for someone that can help me with a IP that appears banned > from the PS4 network. If you are around, please hit me off-list J > > > > Thanx, > > > > > > *Dennis Burgess, Mikrotik Certified Trainer * > > Author of "Learn RouterOS- Second Edition” > > *Link Technologies, Inc* -- Mikrotik & WISP Support Services > > *Office*: 314-735-0270 <(314)%20735-0270> Website: > http://www.linktechs.net > > Create Wireless Coverage’s with www.towercoverage.com > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at 6by7.net Sat Sep 15 05:40:13 2018 From: ben at 6by7.net (Ben Cannon) Date: Fri, 14 Sep 2018 22:40:13 -0700 Subject: Where to buy a CLEC Message-ID: <6584A3EE-8406-4604-A4E6-BEC7CA24A65A@6by7.net> I have a need to accelerate our Full Facilities CLC program dramatically, faster than a new application can be completed, and would like to purchase an existing Full Facilities CLC / CLEC. Where’s a good place to even find a marketplace for this? Note: interested parties can contact me off list, be advised I’m looking for something small/basic. -Ben From tj at pcguys.us Sat Sep 15 06:27:56 2018 From: tj at pcguys.us (TJ Trout) Date: Fri, 14 Sep 2018 23:27:56 -0700 Subject: Playstation/Sony Support In-Reply-To: References: <1fdd77f20ca84c508424e99f0ffeb92c@linktechs.net> Message-ID: snei-noc-abuse () am.sony.com On Fri, Sep 14, 2018 at 3:39 PM, Matthew Kaufman wrote: > Every IP of mine that's banned is banned because of a hacked Mikrotik > router. Despite keeping up with the numerous updates, it seems almost every > one I own got hit in the last week. > > Matthew Kaufman > > On Fri, Sep 14, 2018 at 11:13 AM Dennis Burgess via NANOG > wrote: > >> I am looking for someone that can help me with a IP that appears banned >> from the PS4 network. If you are around, please hit me off-list J >> >> >> >> Thanx, >> >> >> >> >> >> *Dennis Burgess, Mikrotik Certified Trainer * >> >> Author of "Learn RouterOS- Second Edition” >> >> *Link Technologies, Inc* -- Mikrotik & WISP Support Services >> >> *Office*: 314-735-0270 <(314)%20735-0270> Website: >> http://www.linktechs.net >> >> Create Wireless Coverage’s with www.towercoverage.com >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From geier at geier.ne.tz Sat Sep 15 07:28:35 2018 From: geier at geier.ne.tz (Frank Habicht) Date: Sat, 15 Sep 2018 10:28:35 +0300 Subject: Puerto Rico Internet Exchange In-Reply-To: References: <51FB6344-113D-4D78-BE7E-349BC41F5958@beckman.org> Message-ID: <8069f126-c4e1-9fa9-4c2b-c2642047cf6f@geier.ne.tz> Hi, On 14/09/2018 16:08, Sander Steffann wrote: >> In general an IX only makes sense when there are local resources to >> exchange. It doesn’t seem like PR has a lot of, if any, content >> providers of its own, so most consumer content is coming from >> offshore anyway. > > This can also work the other way: once there is a local IXP, it can > open opportunities for local content providers. > > Cheers, Sander I'd also think that if there is sufficient local motivation, the local guys should get something started for their own purposes. And that would maybe not immediately include "big content", but it would keep their own domestic traffic local. So even if it's not lots of Gigabits immediately, even if the latency "penalty" without local peering isn't that big, it would still cost them something to pass traffic through the water, and a local IXP should be cheaper if run with low overhead... Establishing an "aggregation point" would be the first step, and then outsiders can see what's possible there. Frank not knowing much about the specific environment From nanog at ics-il.net Sat Sep 15 15:02:10 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 15 Sep 2018 10:02:10 -0500 (CDT) Subject: Playstation/Sony Support In-Reply-To: References: <1fdd77f20ca84c508424e99f0ffeb92c@linktechs.net> Message-ID: <1177341583.3274.1537023727638.JavaMail.mhammett@ThunderFuck> https://www.facebook.com/thebrotherswisp/posts/1695981100527335 ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Matthew Kaufman" To: "Dennis Burgess" Cc: nanog at nanog.org Sent: Friday, September 14, 2018 5:39:41 PM Subject: Re: Playstation/Sony Support Every IP of mine that's banned is banned because of a hacked Mikrotik router. Despite keeping up with the numerous updates, it seems almost every one I own got hit in the last week. Matthew Kaufman On Fri, Sep 14, 2018 at 11:13 AM Dennis Burgess via NANOG < nanog at nanog.org > wrote: I am looking for someone that can help me with a IP that appears banned from the PS4 network. If you are around, please hit me off-list J Thanx, Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition” Link Technologies, Inc -- Mikrotik & WISP Support Services Office : 314-735-0270 Website: http://www.linktechs.net Create Wireless Coverage’s with www.towercoverage.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmarion66 at gmail.com Sat Sep 15 16:41:34 2018 From: dmarion66 at gmail.com (David Marion) Date: Sat, 15 Sep 2018 11:41:34 -0500 Subject: Where to buy a CLEC In-Reply-To: <6584A3EE-8406-4604-A4E6-BEC7CA24A65A@6by7.net> References: <6584A3EE-8406-4604-A4E6-BEC7CA24A65A@6by7.net> Message-ID: Geographic region? On Sat, Sep 15, 2018, 12:41 AM Ben Cannon wrote: > I have a need to accelerate our Full Facilities CLC program dramatically, > faster than a new application can be completed, and would like to purchase > an existing Full Facilities CLC / CLEC. Where’s a good place to even find > a marketplace for this? > > Note: interested parties can contact me off list, be advised I’m looking > for something small/basic. > > -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Sat Sep 15 16:56:33 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 15 Sep 2018 19:56:33 +0300 Subject: What NMS do you use and why? In-Reply-To: References: Message-ID: On 15/Aug/18 15:49, Colton Conor wrote: > We are looking for a new network monitoring system. Since there are so > many operators on this list, I would like to know which NMS do you use > and why? Is there one that you really like, and others that you hate?  > > For free options (opensouce), LibreNMS and NetXMS come highly > recommended by many wireless ISPs on low budgets. However, I am not > sure the commercial options available nor their price points. We run Iris - home-grown (South Africa), great support, small/nimble team that are able to fix issue, add features and give advice. Very flexible, captures plenty of data out-the-box, supports a ton of vendors and data points, e.t.c. It's a commercial solution, but not out of reach. Heck, even I can afford it :-).     http://www.irisns.com/ We moved from a Cacti/SmokePing/Observium/Zabbix combo to Iris 2 years ago. Much happiness. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From outsider at scarynet.org Sun Sep 16 10:48:57 2018 From: outsider at scarynet.org (Alexander Maassen) Date: Sun, 16 Sep 2018 12:48:57 +0200 Subject: Proofpoint Message-ID: Could someone from proofpoint contact me regarding the return of the issue mentioned at https://dronebl.org/blog/35, because it seems that still has not been fixed. From mehmet at akcin.net Sun Sep 16 19:51:05 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Sun, 16 Sep 2018 12:51:05 -0700 Subject: Puerto Rico Internet Exchange In-Reply-To: <8069f126-c4e1-9fa9-4c2b-c2642047cf6f@geier.ne.tz> References: <51FB6344-113D-4D78-BE7E-349BC41F5958@beckman.org> <8069f126-c4e1-9fa9-4c2b-c2642047cf6f@geier.ne.tz> Message-ID: Thank you very much everyone for so many private and public responses. We've setup a smaller and focused discussion group for the parties interested in discussing Puerto Rico Internet Exchange Project. You can subscribe here https://groups.google.com/a/puertorico-ix.com . I have received some tremendous private support to proceed with this project and we will do so, trying our best. mehmet On Sat, Sep 15, 2018 at 12:29 AM Frank Habicht wrote: > Hi, > > On 14/09/2018 16:08, Sander Steffann wrote: > >> In general an IX only makes sense when there are local resources to > >> exchange. It doesn’t seem like PR has a lot of, if any, content > >> providers of its own, so most consumer content is coming from > >> offshore anyway. > > > > This can also work the other way: once there is a local IXP, it can > > open opportunities for local content providers. > > > > Cheers, Sander > > I'd also think that if there is sufficient local motivation, the local > guys should get something started for their own purposes. > > And that would maybe not immediately include "big content", but it would > keep their own domestic traffic local. So even if it's not lots of > Gigabits immediately, even if the latency "penalty" without local > peering isn't that big, it would still cost them something to pass > traffic through the water, and a local IXP should be cheaper if run with > low overhead... > > Establishing an "aggregation point" would be the first step, and then > outsiders can see what's possible there. > > Frank > not knowing much about the specific environment > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brak at gameservers.com Mon Sep 17 14:15:43 2018 From: brak at gameservers.com (Brian Rak) Date: Mon, 17 Sep 2018 10:15:43 -0400 Subject: Level3 IRR contact Message-ID: I'm trying to get some old IRR objects removed from the LEVEL3 database, and not having much luck. Their support guys silently closed my ticket and then had our account manager email us directly basically saying "we don't what you want us to do". I used to use routing at level3 to get this done, however they don't seem to reply anymore. http://www.irr.net/docs/list.html directs me to rr at level3.net, which has an autoreply that says "open a ticket" From tom at ninjabadger.net Mon Sep 17 14:18:34 2018 From: tom at ninjabadger.net (Tom Hill) Date: Mon, 17 Sep 2018 15:18:34 +0100 Subject: Level3 IRR contact In-Reply-To: References: Message-ID: <8121ec78-6589-292c-cce0-f7b38937e7ee@ninjabadger.net> On 17/09/18 15:15, Brian Rak wrote: > I used to use routing at level3 to get this done, however they don't seem > to reply anymore. > > http://www.irr.net/docs/list.html directs me to rr at level3.net, which has > an autoreply that says "open a ticket" You may wish to start by swapping the Level3 domain for the CenturyLink one? -- Tom From edugas at unknowndevice.ca Mon Sep 17 14:19:14 2018 From: edugas at unknowndevice.ca (Eric Dugas) Date: Mon, 17 Sep 2018 10:19:14 -0400 Subject: Level3 IRR contact In-Reply-To: References: Message-ID: <1537193797.local-d120dce9-5cde-v1.4.2-f587b7b7@getmailspring.com> If you find someone helpful at L3/CL for your request, I would like to have its contact (off-list). I've been trying to cleanup old objects too without much success. Eric On Sep 17 2018, at 10:15 am, Brian Rak wrote: > > I'm trying to get some old IRR objects removed from the LEVEL3 database, > and not having much luck. > > Their support guys silently closed my ticket and then had our account > manager email us directly basically saying "we don't what you want us to > do". > > I used to use routing at level3 to get this done, however they don't seem > to reply anymore. > > http://www.irr.net/docs/list.html directs me to rr at level3.net, which has > an autoreply that says "open a ticket" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kuenzler at init7.net Mon Sep 17 14:57:45 2018 From: kuenzler at init7.net (Fredy Kuenzler) Date: Mon, 17 Sep 2018 16:57:45 +0200 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC Message-ID: Is anyone else affected by a massive price increase for x-conns by Telehouse Chelsea? When we moved in a few years ago they were asking 150$, it changed to 200$ and now we are asked to pay 260$. That's 73% more. I don't think inflation is that high in the United states. I get the impression that they feel comfortable enough to abuse their position. When we complained they simply said 'you may consider to cancel the contract'. Of course they don't provide any better service, in fact, the service quality is commonly indirectly proportional to the price at most 'big names'. #rant I suggest to anyone considering to buy colocation space in NYC (or elsewhere) not to choose Telehouse, unlike a few years ago. -- Fredy Kuenzler Init7 (Switzerland) Ltd. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From dovid at telecurve.com Mon Sep 17 15:06:20 2018 From: dovid at telecurve.com (Dovid Bender) Date: Mon, 17 Sep 2018 11:06:20 -0400 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: References: Message-ID: Still better than what other places charge (*cough* DR..... *cough*) On Mon, Sep 17, 2018 at 10:57 AM, Fredy Kuenzler wrote: > Is anyone else affected by a massive price increase for x-conns by > Telehouse Chelsea? > > When we moved in a few years ago they were asking 150$, it changed to > 200$ and now we are asked to pay 260$. That's 73% more. I don't think > inflation is that high in the United states. > > I get the impression that they feel comfortable enough to abuse their > position. When we complained they simply said 'you may consider to > cancel the contract'. > > Of course they don't provide any better service, in fact, the service > quality is commonly indirectly proportional to the price at most 'big > names'. #rant > > I suggest to anyone considering to buy colocation space in NYC (or > elsewhere) not to choose Telehouse, unlike a few years ago. > > -- > Fredy Kuenzler > Init7 (Switzerland) Ltd. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethm at rollernet.us Mon Sep 17 15:20:37 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 17 Sep 2018 08:20:37 -0700 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: References: Message-ID: <43a12dfe-d15c-3713-8a23-9d9983e7bdba@rollernet.us> On 9/17/18 7:57 AM, Fredy Kuenzler wrote: > Is anyone else affected by a massive price increase for x-conns by > Telehouse Chelsea? > > When we moved in a few years ago they were asking 150$, it changed to > 200$ and now we are asked to pay 260$. That's 73% more. I don't think > inflation is that high in the United states. > > I get the impression that they feel comfortable enough to abuse their > position. When we complained they simply said 'you may consider to > cancel the contract'. They know that most people will complain, but they very few will actually pull the trigger on a cancel. I see attitudes like this change with ownership or new executives looking to make their mark. Prices will keep going up until whatever metric of how many customers actually cancel is met. If you're able to cancel, I say do it. One of two things will happen: you'll call their bluff and get offered a better rate, or 2) you get to move somewhere that has a better rate and you know to make sure it's contracted or has a cap on how much it can increase on an annual basis. Yes, moving is horribly inconvenient, but in my opinion it's worse to work with a company who is hostile towards their customers. ~Seth From dcorbe at hammerfiber.com Mon Sep 17 15:30:37 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Mon, 17 Sep 2018 11:30:37 -0400 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: References: Message-ID: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> at 10:57 AM, Fredy Kuenzler wrote: > Is anyone else affected by a massive price increase for x-conns by > Telehouse Chelsea? > > When we moved in a few years ago they were asking 150$, it changed to > 200$ and now we are asked to pay 260$. That's 73% more. I don't think > inflation is that high in the United states. > > I get the impression that they feel comfortable enough to abuse their > position. When we complained they simply said 'you may consider to > cancel the contract'. > > Of course they don't provide any better service, in fact, the service > quality is commonly indirectly proportional to the price at most 'big > names'. #rant > > I suggest to anyone considering to buy colocation space in NYC (or > elsewhere) not to choose Telehouse, unlike a few years ago. > > -- > Fredy Kuenzler > Init7 (Switzerland) Ltd. $300 MRC for a once-off cross connect isn’t unreasonable. There’s costs and labor involved in running that cable through a riser. Especially if you want it in innerduct. I’m not sure what Telehouse’s policies are because I’m not a customer, but some companies (TelX comes to mind) you can order them in bulk at a significant discount. Even with the extra labor involved in splicing it to a panel, running a 12 or 24 count cable into a cabinet is a much easier pill to swallow than having a guy up on a ladder or under a floor every time you want to turn up a customer. Then there’s always off-market options too. You don’t need to be in New York to have decent connectivity to the New York metro region. There’s a few places in Jersey that offer free cross connects in their meet-me rooms because they’re so desperate to have carriers move into their facilities. I don’t think many of them have connectivity to major peering fabrics, though. From nusenu-lists at riseup.net Sat Sep 15 13:06:00 2018 From: nusenu-lists at riseup.net (nusenu) Date: Sat, 15 Sep 2018 13:06:00 +0000 Subject: RIR outreach program about INVALIDs (was: deploying RPKI based Origin Validation) In-Reply-To: <6fd6a682-6da7-4a0a-695d-152723be0641@seacom.mu> References: <3a040855-00db-c8e5-e818-255252ee0a6b@seacom.mu> <7a99eb37-748c-77e3-00c4-ea94c64455ce@spamtrap.tnetconsulting.net> <1e5f4da0-0fc7-c277-3bf8-ebb33ec007b1@seacom.mu> <20180716152603.GE42041@vurt.meerval.net> <2d21104f-670d-5c2b-609a-08bb9339e0fc@seacom.mu> <7edc9ec76b0b4952adc91273c9a59416@CRA110.am.necel.com> <8b3764d9-da8d-ea6c-e5a1-28133eb5d0e7@seacom.mu> <6fd6a682-6da7-4a0a-695d-152723be0641@seacom.mu> Message-ID: Job wrote (2018-07-16) [1]: > Perhaps the RIRs should start an outreach program to proactively inform > the owners of those 2,200 invalid route announcements to get them to > either fix or delete the RPKI ROA. Since I'm also interested [2] in reducing the amount of RPKI INVALIDs in an efficient way I was wondering if you proceeded with this and if so what reaction you got from the RIRs. thanks! nusenu [1] https://mailman.nanog.org/pipermail/nanog/2018-July/096202.html [2] https://medium.com/@nusenu/towards-cleaning-up-rpki-invalids-d69b03ab8a8c -- https://twitter.com/nusenu_ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From nusenu-lists at riseup.net Sat Sep 15 13:22:00 2018 From: nusenu-lists at riseup.net (nusenu) Date: Sat, 15 Sep 2018 13:22:00 +0000 Subject: adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor? Message-ID: Dear NIST RPKI Monitor Team, thanks for creating and maintaining the RPKI Monitor https://rpki-monitor.antd.nist.gov/#rpki_adopters I've seen your graphs in multiple routing security presentations :) What do you think about adding graphs that show the amount of actually unreachable prefixes and IP space? (prefix where no alternative valid/unknown announcement exists) I think such graphs would help us focus on those prefixes that we should have to tackle first. This page contains examples of INVALID prefixes that would still be reachable in a route origin validating environment (see the RPKI validator screenshots): https://medium.com/@nusenu/towards-cleaning-up-rpki-invalids-d69b03ab8a8c kind regards, nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From andre.vanzyl at comsol.co.za Mon Sep 17 10:31:56 2018 From: andre.vanzyl at comsol.co.za (Andre van Zyl) Date: Mon, 17 Sep 2018 12:31:56 +0200 Subject: What NMS do you use and why? In-Reply-To: References: Message-ID: <20180917123156.cec3c8354217dd60b12f964e@comsol.co.za> > > We run Iris - home-grown (South Africa), great support, small/nimble > team that are able to fix issue, add features and give advice. > > Very flexible, captures plenty of data out-the-box, supports a ton of > vendors and data points, e.t.c. > > It's a commercial solution, but not out of reach. Heck, even I can > afford it :-). > >     http://www.irisns.com/ > > We moved from a Cacti/SmokePing/Observium/Zabbix combo to Iris 2 years > ago. Much happiness. > > Mark. > +1 for Iris. We've been with them for a couple of years now, and the support has been first class - quick incident response, fast fixes, and very approachable regarding feature requests. They are based out of Cape Town, South Africa, but also have a US presence in the DC area. Andre. From thomasammon at gmail.com Mon Sep 17 10:54:24 2018 From: thomasammon at gmail.com (Tom Ammon) Date: Mon, 17 Sep 2018 06:54:24 -0400 Subject: netflix OCA in a CG-NAT world Message-ID: I'm looking to understand the impact of CG-NAT on a set of netflix OCAs, in an ISP environment. I see in Netflix's FAQ on the subject that traffic sourced from RFC 1918/6598 endpoints can't be delivered to the OCA. Is this simply a matter of deploying the OCA on the outside of the CGN layer? What are the other consequences of CGN upon the OCA? Tom -- ----------------------------------------------------------------------------- Tom Ammon M: (801) 784-2628 thomasammon at gmail.com ----------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnford at uiowa.net Mon Sep 17 15:47:12 2018 From: jnford at uiowa.net (Jay Ford) Date: Mon, 17 Sep 2018 10:47:12 -0500 (CDT) Subject: Level3 IRR contact In-Reply-To: <1537193797.local-d120dce9-5cde-v1.4.2-f587b7b7@getmailspring.com> References: <1537193797.local-d120dce9-5cde-v1.4.2-f587b7b7@getmailspring.com> Message-ID: I had success cleaning up old IRR stuff via email to the contact listed in the AS3561 whois entry. It's a different person listed now, but perhaps they are also interested & responsive. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford at uiowa.edu, phone: 319-335-5555 On Mon, 17 Sep 2018, Eric Dugas wrote: > If you find someone helpful at L3/CL for your request, I would like to have its contact (off-list). I've been trying to > cleanup old objects too without much success. > > Eric > On Sep 17 2018, at 10:15 am, Brian Rak wrote: > > I'm trying to get some old IRR objects removed from the LEVEL3 database, > and not having much luck. > > Their support guys silently closed my ticket and then had our account > manager email us directly basically saying "we don't what you want us to > do". > > I used to use routing at level3 to get this done, however they don't seem > to reply anymore. > > http://www.irr.net/docs/list.html directs me to rr at level3.net, which has > an autoreply that says "open a ticket" From jared at puck.nether.net Mon Sep 17 15:48:22 2018 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 17 Sep 2018 11:48:22 -0400 Subject: netflix OCA in a CG-NAT world In-Reply-To: References: Message-ID: <8862102D-0FD5-47B9-A05A-0BAC3317D733@puck.nether.net> > On Sep 17, 2018, at 6:54 AM, Tom Ammon wrote: > > I'm looking to understand the impact of CG-NAT on a set of netflix OCAs, in an ISP environment. I see in Netflix's FAQ on the subject that traffic sourced from RFC 1918/6598 endpoints can't be delivered to the OCA. Is this simply a matter of deploying the OCA on the outside of the CGN layer? What are the other consequences of CGN upon the OCA? > Yes, you want to deploy it outside your CG-NAT. I also strongly suggest you look at how to get native IPv6 from your clients behind the CG-NAT rolled out. I know many folks have had issues with various CDNs and the number of devices that reach out. This is why folks get the Google captcha, etc. Giving those end-users an alternate way out will help. I understand this may take effort and is harder for folks using UBNT & Tik gear in a smaller environment, but there is value for your end-users. - Jared From bill at herrin.us Mon Sep 17 15:57:18 2018 From: bill at herrin.us (William Herrin) Date: Mon, 17 Sep 2018 11:57:18 -0400 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> Message-ID: On Mon, Sep 17, 2018 at 11:30 AM, Daniel Corbe wrote: > $300 MRC for a once-off cross connect isn’t unreasonable. There’s costs > and labor involved in running that cable through a riser. Especially if you > want it in innerduct. Hi Daniel, A $300 Non-Recurring Cost, sure. The MONTHLY Recurring Cost of maintaining that cable is not zero, especially if it's in a campus not just one building, but it's pretty close to zero. Charging the customer a $300 MRC may not be unusual but it is unreasonable. I get that floorspace and power is priced pretty close to cost-recovery so that cross connects are one of the only profit centers for a carrier neutral facility. It's still obnoxious. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From job at ntt.net Mon Sep 17 16:15:43 2018 From: job at ntt.net (Job Snijders) Date: Mon, 17 Sep 2018 19:15:43 +0300 Subject: adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor? In-Reply-To: References: Message-ID: On Mon, 17 Sep 2018 at 18:38, nusenu wrote: > Dear NIST RPKI Monitor Team, > > thanks for creating and maintaining the RPKI Monitor > https://rpki-monitor.antd.nist.gov/#rpki_adopters > I've seen your graphs in multiple routing security presentations :) > > What do you think about adding graphs that show the amount of actually > unreachable prefixes and IP space? (prefix where no alternative > valid/unknown announcement exists) > > I think such graphs would help us focus on those prefixes that we should > have to tackle first. Agreed. Increased visibility will help all of us. Tracking this data over time would be a beneficial tool. This page contains examples of INVALID prefixes that would still be > reachable in a route origin validating > environment (see the RPKI validator screenshots): > https://medium.com/@nusenu/towards-cleaning-up-rpki-invalids-d69b03ab8a8c Nusenu thank you for your thorough analysis. This is very useful information. Kind regards, Job -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Sep 17 18:53:37 2018 From: owen at delong.com (Owen DeLong) Date: Mon, 17 Sep 2018 11:53:37 -0700 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> Message-ID: <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> If it’s in an interduct by itself, how much would the square footage per month occupied by the average cross connect be worth? I’m not saying I think $300 MRC is legitimate by any means, but, if you’re going to talk about the ongoing costs, the space in the cable ladder and/or fiber tray(s) also has to be accounted for. Owen > On Sep 17, 2018, at 8:57 AM, William Herrin wrote: > > On Mon, Sep 17, 2018 at 11:30 AM, Daniel Corbe wrote: >> $300 MRC for a once-off cross connect isn’t unreasonable. There’s costs >> and labor involved in running that cable through a riser. Especially if you >> want it in innerduct. > > Hi Daniel, > > A $300 Non-Recurring Cost, sure. The MONTHLY Recurring Cost of > maintaining that cable is not zero, especially if it's in a campus not > just one building, but it's pretty close to zero. Charging the > customer a $300 MRC may not be unusual but it is unreasonable. > > I get that floorspace and power is priced pretty close to > cost-recovery so that cross connects are one of the only profit > centers for a carrier neutral facility. It's still obnoxious. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: From owen at delong.com Mon Sep 17 18:55:04 2018 From: owen at delong.com (Owen DeLong) Date: Mon, 17 Sep 2018 11:55:04 -0700 Subject: netflix OCA in a CG-NAT world In-Reply-To: <8862102D-0FD5-47B9-A05A-0BAC3317D733@puck.nether.net> References: <8862102D-0FD5-47B9-A05A-0BAC3317D733@puck.nether.net> Message-ID: > On Sep 17, 2018, at 8:48 AM, Jared Mauch wrote: > > > >> On Sep 17, 2018, at 6:54 AM, Tom Ammon wrote: >> >> I'm looking to understand the impact of CG-NAT on a set of netflix OCAs, in an ISP environment. I see in Netflix's FAQ on the subject that traffic sourced from RFC 1918/6598 endpoints can't be delivered to the OCA. Is this simply a matter of deploying the OCA on the outside of the CGN layer? What are the other consequences of CGN upon the OCA? >> > > Yes, you want to deploy it outside your CG-NAT. > > I also strongly suggest you look at how to get native IPv6 from your clients behind the CG-NAT rolled out. I know many folks have had issues with various CDNs and the number of devices that reach out. This is why folks get the Google captcha, etc. > > Giving those end-users an alternate way out will help. I understand this may take effort and is harder for folks using UBNT & Tik gear in a smaller environment, but there is value for your end-users. > > - Jared > Actually, Tik gear fully supports IPv6, so only UBNT gear is really an issue here. Owen From telmnstr at 757.org Mon Sep 17 19:08:52 2018 From: telmnstr at 757.org (Ethan O'Toole) Date: Mon, 17 Sep 2018 15:08:52 -0400 (EDT) Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> Message-ID: > If it’s in an interduct by itself, how much would the square footage per > month occupied by the average cross connect be worth? These big datacenter companies are REITs. Similar to self-storage units and apartment buildings, they exist to extract as much money as possible from the users. Nothing more or nothing less. The price relief only comes when the market is grossly overbuilt and if there is actual competition. - Ethan O'Toole From ben at 6by7.net Mon Sep 17 19:33:16 2018 From: ben at 6by7.net (Ben Cannon) Date: Mon, 17 Sep 2018 12:33:16 -0700 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> Message-ID: <8A48B84A-7284-43D4-826D-108F9E1EF71C@6by7.net> $350/mo seems to be standard. Our DCs are at $250. Seems more like they held onto out of date pricing for a long time then realized it. -Ben On Sep 17, 2018, at 12:08 PM, Ethan O'Toole wrote: >> If it’s in an interduct by itself, how much would the square footage per >> month occupied by the average cross connect be worth? > > These big datacenter companies are REITs. Similar to self-storage units and apartment buildings, they exist to extract as much money as possible from the users. Nothing more or nothing less. The price relief only comes when the market is grossly overbuilt and if there is actual competition. > > - Ethan O'Toole From patrick at ianai.net Mon Sep 17 19:40:38 2018 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 17 Sep 2018 15:40:38 -0400 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> Message-ID: <5C301DB9-C314-4565-9F7F-17EFB36938DC@ianai.net> On Sep 17, 2018, at 15:08, Ethan O'Toole wrote: > >> If it’s in an interduct by itself, how much would the square footage per >> month occupied by the average cross connect be worth? > > These big datacenter companies are REITs. Similar to self-storage units and apartment buildings, they exist to extract as much money as possible from the users. Nothing more or nothing less. The price relief only comes when the market is grossly overbuilt and if there is actual competition. Maybe I am confused, but I thought every for-profit business exists to extract as much money as possible. When a business gives you something for free, they are expecting something in return - return business, personal data, lower churn, good reviews, customer loyalty, etc. - that they can turn into cash. Any business with little or no competition can be expected to raise prices. This is not exactly new or surprising. Expecting any for-profit business (all of them, not just REITs) to do less than extract maximum cash is deluding yourself. -- TTFN, patrick From jmaimon at jmaimon.com Mon Sep 17 19:54:55 2018 From: jmaimon at jmaimon.com (Joe Maimon) Date: Mon, 17 Sep 2018 15:54:55 -0400 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> Message-ID: <5BA0068F.10904@jmaimon.com> Ethan O'Toole wrote: >> If it’s in an interduct by itself, how much would the square footage per >> month occupied by the average cross connect be worth? > > These big datacenter companies are REITs. Similar to self-storage > units and apartment buildings, they exist to extract as much money as > possible from the users. Nothing more or nothing less. The price > relief only comes when the market is grossly overbuilt and if there is > actual competition. > > - Ethan O'Toole > > For a positive side effect, xcon pricing should bring greater demand to dwdm solutions, what would you recommend for an affordable 1u turnkey buy a pair and get >10<30 1g/10g maybe a couple of 40 even a 100g (and mon/expansion)? Joe From dougm at nist.gov Mon Sep 17 16:46:06 2018 From: dougm at nist.gov (Montgomery, Douglas (Fed)) Date: Mon, 17 Sep 2018 16:46:06 +0000 Subject: [proj-bgp] adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor? In-Reply-To: References: Message-ID: <789C4684-5538-4613-BF37-F1FF810711CA@nist.gov> Job, Thanks for the input, we have a new version of our RPKI monitor that we are in the process of moving from development systems to publicly accessible servers. The new monitor has significant additions in the areas of diagnostics, and highlights issues of interest such as path / customer cone analysis of prefixes that cover invalid originations. We break down basic coverage stats – i.e., what is still routable assuming drop invalid policy. [cid:image001.png at 01D44E84.65DD2B70] And for the covering valid or not found prefixes we provide path analyses of various sorts. [cid:image002.png at 01D44E84.65DD2B70] Other new diagnostics will map changes in origin validation state to specific changes in RPKI data – i.e., answering the question what changed? And why? I will send a link when we get things moved to a public facing server. dougm -- Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST From: on behalf of Job Snijders Date: Monday, September 17, 2018 at 12:23 PM To: nusenu Cc: rpki-monitor , "nanog at nanog.org" Subject: Re: [proj-bgp] adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor? On Mon, 17 Sep 2018 at 18:38, nusenu > wrote: Dear NIST RPKI Monitor Team, thanks for creating and maintaining the RPKI Monitor https://rpki-monitor.antd.nist.gov/#rpki_adopters I've seen your graphs in multiple routing security presentations :) What do you think about adding graphs that show the amount of actually unreachable prefixes and IP space? (prefix where no alternative valid/unknown announcement exists) I think such graphs would help us focus on those prefixes that we should have to tackle first. Agreed. Increased visibility will help all of us. Tracking this data over time would be a beneficial tool. This page contains examples of INVALID prefixes that would still be reachable in a route origin validating environment (see the RPKI validator screenshots): https://medium.com/@nusenu/towards-cleaning-up-rpki-invalids-d69b03ab8a8c Nusenu thank you for your thorough analysis. This is very useful information. Kind regards, Job -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at 6by7.net Mon Sep 17 20:23:42 2018 From: ben at 6by7.net (Ben Cannon) Date: Mon, 17 Sep 2018 13:23:42 -0700 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: <5BA0068F.10904@jmaimon.com> References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> <5BA0068F.10904@jmaimon.com> Message-ID: fs.com has got this ready to go. Less than that. > On Sep 17, 2018, at 12:54 PM, Joe Maimon wrote: > > > > Ethan O'Toole wrote: >>> If it’s in an interduct by itself, how much would the square footage per >>> month occupied by the average cross connect be worth? >> >> These big datacenter companies are REITs. Similar to self-storage units and apartment buildings, they exist to extract as much money as possible from the users. Nothing more or nothing less. The price relief only comes when the market is grossly overbuilt and if there is actual competition. >> >> - Ethan O'Toole >> >> > For a positive side effect, xcon pricing should bring greater demand to dwdm solutions, what would you recommend for an affordable 1u turnkey buy a pair and get >10<30 1g/10g maybe a couple of 40 even a 100g (and mon/expansion)? > > > Joe From phil.lavin at cloudcall.com Mon Sep 17 20:26:40 2018 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Mon, 17 Sep 2018 20:26:40 +0000 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: <8A48B84A-7284-43D4-826D-108F9E1EF71C@6by7.net> References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> <8A48B84A-7284-43D4-826D-108F9E1EF71C@6by7.net> Message-ID: > $350/mo seems to be standard. Our DCs are at $250. Seems more like they held onto out of date pricing for a long time then realized it. For what it's worth, Telehouse London is around 30 USD/month for an x-connect within the same building. Our US datacentre (not Telehouse) on the other hand is around 200 USD/month. It's always felt disproportionally expensive but maybe those kind of prices are expected for the North America region. From michel.py at tsisemi.com Mon Sep 17 20:39:00 2018 From: michel.py at tsisemi.com (Michel Py) Date: Mon, 17 Sep 2018 20:39:00 +0000 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: <5C301DB9-C314-4565-9F7F-17EFB36938DC@ianai.net> References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> <5C301DB9-C314-4565-9F7F-17EFB36938DC@ianai.net> Message-ID: <819f3c5f6a47496594b200ab33225081@CRA110.am.necel.com> > Patrick W. Gilmore wrote : > Maybe I am confused, but I thought every for-profit business exists to extract as much money as possible. Especially is said business is potentially in my 401(k) portfolio. I expect them to milk every penny they possibly can out of their customers so my 401(k) grows. Oh, wait ? I'm one of their customers. They should milk everyone else, but not me of course. What's the name of this thing ? capitalism ? Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From jbothe at me.com Mon Sep 17 21:12:39 2018 From: jbothe at me.com (JASON BOTHE) Date: Mon, 17 Sep 2018 16:12:39 -0500 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> <5BA0068F.10904@jmaimon.com> Message-ID: <8A128236-EE50-40FD-B41F-B3A210EA2123@me.com> Correct. Behold the ‘active riser’. We started doing this years ago in our R&E network after we were being nickeled and dimes to cross floors between our own cages we leased from the same colo. > On Sep 17, 2018, at 15:23, Ben Cannon wrote: > > fs.com has got this ready to go. Less than that. > >> On Sep 17, 2018, at 12:54 PM, Joe Maimon wrote: >> >> >> >> Ethan O'Toole wrote: >>>> If it’s in an interduct by itself, how much would the square footage per >>>> month occupied by the average cross connect be worth? >>> >>> These big datacenter companies are REITs. Similar to self-storage units and apartment buildings, they exist to extract as much money as possible from the users. Nothing more or nothing less. The price relief only comes when the market is grossly overbuilt and if there is actual competition. >>> >>> - Ethan O'Toole >>> >>> >> For a positive side effect, xcon pricing should bring greater demand to dwdm solutions, what would you recommend for an affordable 1u turnkey buy a pair and get >10<30 1g/10g maybe a couple of 40 even a 100g (and mon/expansion)? >> >> >> Joe > From ross at tajvar.io Mon Sep 17 21:20:57 2018 From: ross at tajvar.io (Ross Tajvar) Date: Mon, 17 Sep 2018 17:20:57 -0400 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> <8A48B84A-7284-43D4-826D-108F9E1EF71C@6by7.net> Message-ID: My current facility (in the Ashburn, VA, USA area) is $25/mo with two for free, but when I was shopping around, most other facilities were at least $300/mo. Certainly not unusual but I agree it's excessive. On Mon, Sep 17, 2018 at 4:26 PM, Phil Lavin wrote: > > $350/mo seems to be standard. Our DCs are at $250. Seems more like > they held onto out of date pricing for a long time then realized it. > > For what it's worth, Telehouse London is around 30 USD/month for an > x-connect within the same building. Our US datacentre (not Telehouse) on > the other hand is around 200 USD/month. It's always felt disproportionally > expensive but maybe those kind of prices are expected for the North America > region. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcorbe at hammerfiber.com Mon Sep 17 21:29:03 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Mon, 17 Sep 2018 17:29:03 -0400 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> <8A48B84A-7284-43D4-826D-108F9E1EF71C@6by7.net> Message-ID: <72FF3D34-841C-473A-9FA6-5B516B3D3212@hammerfiber.com> at 4:26 PM, Phil Lavin wrote: >> $350/mo seems to be standard. Our DCs are at $250. Seems more like >> they held onto out of date pricing for a long time then realized it. > > For what it's worth, Telehouse London is around 30 USD/month for an > x-connect within the same building. Our US datacentre (not Telehouse) on > the other hand is around 200 USD/month. It's always felt > disproportionally expensive but maybe those kind of prices are expected > for the North America region. Yeah $30 is definitely not the norm on this side of the pond. Even if you buy in bulk. From nick at foobar.org Mon Sep 17 21:51:23 2018 From: nick at foobar.org (Nick Hilliard) Date: Tue, 18 Sep 2018 00:51:23 +0300 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: <5C301DB9-C314-4565-9F7F-17EFB36938DC@ianai.net> References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> <5C301DB9-C314-4565-9F7F-17EFB36938DC@ianai.net> Message-ID: <2229c651-b04a-9ae0-4b29-ac5662dd186a@foobar.org> Patrick W. Gilmore wrote on 17/09/2018 22:40: > Expecting any for-profit business (all of them, not just REITs) to do > less than extract maximum cash is deluding yourself. oh sure, but price gouging is often bad business practice in the long term. Humans evolved a strong sense of injustice and have a long memory for people and organisations whom they feel take advantage of them. As someone else pointed out, business practices like this can work in a rising market, but not so well when market conditions become difficult and people end up in a position of being able to make a choice between organisations which may have treated them badly in the past and those which have not. Nick From patrick at ianai.net Mon Sep 17 21:57:43 2018 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 17 Sep 2018 17:57:43 -0400 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: <2229c651-b04a-9ae0-4b29-ac5662dd186a@foobar.org> References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> <5C301DB9-C314-4565-9F7F-17EFB36938DC@ianai.net> <2229c651-b04a-9ae0-4b29-ac5662dd186a@foobar.org> Message-ID: <61CBB823-FF1E-4C47-BF41-8C034D1D3259@ianai.net> On Sep 17, 2018, at 17:51, Nick Hilliard wrote: > Patrick W. Gilmore wrote on 17/09/2018 22:40: >> Expecting any for-profit business (all of them, not just REITs) to do >> less than extract maximum cash is deluding yourself. > oh sure, but price gouging is often bad business practice in the long term. Humans evolved a strong sense of injustice and have a long memory for people and organisations whom they feel take advantage of them. > > As someone else pointed out, business practices like this can work in a rising market, but not so well when market conditions become difficult and people end up in a position of being able to make a choice between organisations which may have treated them badly in the past and those which have not. No argument. You cut out part of my reply: When a business gives you something for free, they are expecting something in return - return business, personal data, lower churn, good reviews, customer loyalty, etc. - that they can turn into cash. Any business with little or no competition can be expected to raise prices. This is not exactly new or surprising. If you “s/free/free or lower cost/“, it satisfies your statement as well. Every business should be deciding “how much can I make -long term-“, and take into account what you, I, and others have said here. Some will think short term, and (hopefully) the market will punish them over time. Anyway, I think everyone on the thread agrees. Xconn fees are higher than they should be, but not necessarily higher than the market will bear. Yet. Besides, once everyone turns up a single 100 Tbps port to PacketFabric (or two for redundancy), xconn fees will be irrelevant. :-) -- TTFN, patrick From kotikalapudi.sriram at nist.gov Tue Sep 18 00:44:54 2018 From: kotikalapudi.sriram at nist.gov (Sriram, Kotikalapudi (Fed)) Date: Tue, 18 Sep 2018 00:44:54 +0000 Subject: [proj-bgp] adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor? In-Reply-To: References: , Message-ID: Nusenu, I also found your analysis very interesting and useful. Thanks for that. >What do you think about adding graphs that show the amount of actually >unreachable prefixes and IP space? (prefix where no alternative valid/unknown announcement exists) I am also part of the NIST BGP team. Doug has already responded with information that we will soon have a new version of the NIST Monitor which will provide the kind of graphs that you requested. As an additional piece of info, I had given a presentation at IETF 101 in which you may find the data in slides 10-13 interesting: https://datatracker.ietf.org/meeting/101/materials/slides-101-sidrops-origin-validation-policy-considerations-for-dropping-invalid-routes-00 It is a snapshot -- takes update data from Routeviews and validates routes using ROAs (see slides 10-13). Then it drills down on Invalid routes to see how many are covered by Valid (V) or NotFound (NF) less specific routes. Then further drills down to see if the origin AS (OAS) in the V/NF less specific route is the same or different compared to the OAS in the Invalid route. In many cases, the answer is yes - same OAS. We also found that when the answer was 'different OAS', then interestingly, in many instances the OAS in the V/NF less specific route was the transit provider of the OAS in the Invalid route! We (together with Job) have a draft in the IETF SIDROPS WG that specifies the details of DISR (Drop Invalid if Still Routable) policy: https://tools.ietf.org/html/draft-sriram-sidrops-drop-invalid-policy-01 DISR policy is basically what we are discussing here: Drop Invalid if a Valid or NotFound less specific route exists. When one designs implementable policy based on this, some nuances are important to consider. The draft and the slides attempt to do that. Sriram From michel.py at tsisemi.com Tue Sep 18 03:04:02 2018 From: michel.py at tsisemi.com (Michel Py) Date: Tue, 18 Sep 2018 03:04:02 +0000 Subject: [proj-bgp] adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor? In-Reply-To: <789C4684-5538-4613-BF37-F1FF810711CA@nist.gov> References: <789C4684-5538-4613-BF37-F1FF810711CA@nist.gov> Message-ID: <17f419236905494fa2000696f23054f6@CRA110.am.necel.com> Doug, > Montgomery, Douglas wrote : > The new monitor has significant additions in the areas of diagnostics, and highlights issues of > interest such as path / customer cone analysis of prefixes that cover invalid originations. Thanks for all the work. More visibility will help. I have made some private suggestions to how you could enhance the service, and I would add one : provide a BGP feed available to the public with invalid RPKI prefixes with a distinct BGP community describing why the prefix is invalid. We are in an impossible situation where ISPs don't want to discard invalid RPKI prefixes because they can't deal with the customer backshlash of doing it; nothing to gain, money to lose. Money wins. There is another side of this coin, though : you are a government employee. I pay you. As a taxpayer, I think the US governement should provide a better service to US companies with theRPKI collected data. Analysis without action is interesting, but not always federal funding. Best regards, Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From ben at 6by7.net Tue Sep 18 03:50:49 2018 From: ben at 6by7.net (Ben Cannon) Date: Mon, 17 Sep 2018 20:50:49 -0700 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: <72FF3D34-841C-473A-9FA6-5B516B3D3212@hammerfiber.com> References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> <8A48B84A-7284-43D4-826D-108F9E1EF71C@6by7.net> <72FF3D34-841C-473A-9FA6-5B516B3D3212@hammerfiber.com> Message-ID: <0BD69B9A-47B5-4291-A018-1954560A9A12@6by7.net> One Wilshire is at $750/mo for XCs. Expect other constrained buildings to head there if not already (PAIX? Can you even get one?) -Ben. > On Sep 17, 2018, at 2:29 PM, Daniel Corbe wrote: > > at 4:26 PM, Phil Lavin wrote: > >>> $350/mo seems to be standard. Our DCs are at $250. Seems more like they held onto out of date pricing for a long time then realized it. >> >> For what it's worth, Telehouse London is around 30 USD/month for an x-connect within the same building. Our US datacentre (not Telehouse) on the other hand is around 200 USD/month. It's always felt disproportionally expensive but maybe those kind of prices are expected for the North America region. > > Yeah $30 is definitely not the norm on this side of the pond. Even if you buy in bulk. From hank at efes.iucc.ac.il Tue Sep 18 04:42:55 2018 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 18 Sep 2018 07:42:55 +0300 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> <8A48B84A-7284-43D4-826D-108F9E1EF71C@6by7.net> Message-ID: <3d5f160c-c06c-6b13-0588-e1ee2ddacb30@efes.iucc.ac.il> On 17/09/2018 23:26, Phil Lavin wrote: >> $350/mo seems to be standard. Our DCs are at $250. Seems more like they held onto out of date pricing for a long time then realized it. > For what it's worth, Telehouse London is around 30 USD/month for an x-connect within the same building. Our US datacentre (not Telehouse) on the other hand is around 200 USD/month. It's always felt disproportionally expensive but maybe those kind of prices are expected for the North America region. Current list price for 10G Xconnect at the major colo site in Israel is $5840/month.   Discounts are available :-) Keep complaining about $350/mo costs.  You have no idea how lucky you are. -Hank From morrowc.lists at gmail.com Tue Sep 18 05:02:09 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 17 Sep 2018 22:02:09 -0700 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: <3d5f160c-c06c-6b13-0588-e1ee2ddacb30@efes.iucc.ac.il> References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> <8A48B84A-7284-43D4-826D-108F9E1EF71C@6by7.net> <3d5f160c-c06c-6b13-0588-e1ee2ddacb30@efes.iucc.ac.il> Message-ID: On Mon, Sep 17, 2018 at 9:44 PM Hank Nussbacher wrote: > On 17/09/2018 23:26, Phil Lavin wrote: > >> $350/mo seems to be standard. Our DCs are at $250. Seems more like > they held onto out of date pricing for a long time then realized it. > > For what it's worth, Telehouse London is around 30 USD/month for an > x-connect within the same building. Our US datacentre (not Telehouse) on > the other hand is around 200 USD/month. It's always felt disproportionally > expensive but maybe those kind of prices are expected for the North America > region. > Current list price for 10G Xconnect at the major colo site in Israel is > $5840/month. Discounts are available :-) > Keep complaining about $350/mo costs. You have no idea how lucky you are. > > it's funny/possible that x-connect costs affect where peering appears in the landscape, right? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hank at efes.iucc.ac.il Tue Sep 18 06:19:41 2018 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 18 Sep 2018 09:19:41 +0300 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> <8A48B84A-7284-43D4-826D-108F9E1EF71C@6by7.net> <3d5f160c-c06c-6b13-0588-e1ee2ddacb30@efes.iucc.ac.il> Message-ID: On 18/09/2018 08:02, Christopher Morrow wrote: > > > On Mon, Sep 17, 2018 at 9:44 PM Hank Nussbacher > wrote: > > On 17/09/2018 23:26, Phil Lavin wrote: > >> $350/mo seems to be standard. Our DCs are at $250.    Seems > more like they held onto out of date pricing for a long time then > realized it. > > For what it's worth, Telehouse London is around 30 USD/month for > an x-connect within the same building. Our US datacentre (not > Telehouse) on the other hand is around 200 USD/month. It's always > felt disproportionally expensive but maybe those kind of prices > are expected for the North America region. > Current list price for 10G Xconnect at the major colo site in > Israel is > $5840/month.   Discounts are available :-) > Keep complaining about $350/mo costs.  You have no idea how lucky > you are. > > > it's funny/possible that x-connect costs affect where peering appears > in the landscape, right?  Not this time.  Just price gouging since moving a number of cabinets to a different location is a nightmare. -Hank -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at radu-adrian.feurdean.net Tue Sep 18 08:20:32 2018 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Tue, 18 Sep 2018 10:20:32 +0200 Subject: netflix OCA in a CG-NAT world In-Reply-To: <8862102D-0FD5-47B9-A05A-0BAC3317D733@puck.nether.net> References: <8862102D-0FD5-47B9-A05A-0BAC3317D733@puck.nether.net> Message-ID: <1537258832.1038722.1511816800.3B49BDE6@webmail.messagingengine.com> On Mon, Sep 17, 2018, at 17:48, Jared Mauch wrote: > I also strongly suggest you look at how to get native IPv6 from your > clients behind the CG-NAT rolled out. I know many folks have had issues Getting IPv6 to your customers is good, but they still have to use it. If I look at my stats, I can see that the IPv4:IPv6 ratio for Netflix is 5.5:1, while for Google it's 1.1:1 and for Facebook 1.33:1 (peak-time ratios, when traffic is mostly from residential users) . The best explanation I could get is people may use Netflix from devices that do not support IPv6, such as some/most (not-so-old) Smart TVs. There's also the issue of some brain-dead wifi APs that filter or severely limit traffic required for proper IPv6 operation (multicast comes to my mind). I'm not even mentioning the situation in the "pro"/"enterprise" world (much worse) since it doesn't (or it's not supposed to) generate much Netflix traffic (still, during the morning IPv4:IPv6 ratio for Netflix can go as low as 3.5:1). -- R-A.F. From nanog at radu-adrian.feurdean.net Tue Sep 18 08:33:38 2018 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Tue, 18 Sep 2018 10:33:38 +0200 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> Message-ID: <1537259618.1040563.1511834240.4820A544@webmail.messagingengine.com> On Mon, Sep 17, 2018, at 17:30, Daniel Corbe wrote: > $300 MRC for a once-off cross connect isn’t unreasonable. There’s costs 300$ would be (at the limit of) reasonable *M*RC for a 12 FO cable (= 6 duplex XCOs). Or the one-off (*N*RC) for one XCO. That's actually close to the rates we have on this part of the ocean. 300$ for one XCO (2 FO) is "robbery in organised band" (word-by-word translation of a french legal term). You can get metro waves (some 10-20 km distance) for lower than that (again, on my part of the ocean). -- R-A.F. From alan at routingloop.com Tue Sep 18 13:36:33 2018 From: alan at routingloop.com (Alan Hannan) Date: Tue, 18 Sep 2018 08:36:33 -0500 Subject: Console Servers Message-ID: I'd like your input on suggestions for an alternate serial port manager. Long ago I used Cisco 2511/2611 and was fairly happy. A little later I used portmaster and was less so. Recently I've been using Opengear and they work fairly well but the price is fairly high. I use the CM7100 and IM7100. General specs I'm looking for are: * 8 to 48 or more rs232 serial ports on rj45 * nice-to-have software selectable pinouts (cisco v. straight) * gig-e ethernet port (100mbps ok) * 1U form factor * redundant AC power * access physical serial connections via local port # * access physical serial connections via local IP alias (nice to have) Can you recommend a serial port server/concentrator that I could use in place of opengear for a better value and/or lower cost? I'm just ignorant about the current market for serial port concentrators and so far web searches have not revealed ideas, so your input is appreciated! Thanks! -alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From stano at imaginesoftware.com Tue Sep 18 13:43:37 2018 From: stano at imaginesoftware.com (Stan Ouchakov) Date: Tue, 18 Sep 2018 13:43:37 +0000 Subject: Console Servers In-Reply-To: References: Message-ID: <0ca3304a6670458bbe2e24510ef30ba1@imaginesoftware.com> Depending on the budget, refurbished Cyclades off ebay do the job well. Very solid and proven products, we still run few dated from 2003 … -Stan From: NANOG On Behalf Of Alan Hannan Sent: Tuesday, September 18, 2018 9:37 AM To: NANOG Subject: Console Servers I'd like your input on suggestions for an alternate serial port manager. Long ago I used Cisco 2511/2611 and was fairly happy. A little later I used portmaster and was less so. Recently I've been using Opengear and they work fairly well but the price is fairly high. I use the CM7100 and IM7100. General specs I'm looking for are: * 8 to 48 or more rs232 serial ports on rj45 * nice-to-have software selectable pinouts (cisco v. straight) * gig-e ethernet port (100mbps ok) * 1U form factor * redundant AC power * access physical serial connections via local port # * access physical serial connections via local IP alias (nice to have) Can you recommend a serial port server/concentrator that I could use in place of opengear for a better value and/or lower cost? I'm just ignorant about the current market for serial port concentrators and so far web searches have not revealed ideas, so your input is appreciated! Thanks! -alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Tue Sep 18 13:49:10 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 18 Sep 2018 08:49:10 -0500 (CDT) Subject: Console Servers In-Reply-To: References: Message-ID: <1454495587.5217.1537278546085.JavaMail.mhammett@ThunderFuck> I'm deploying new to me Cisco 2811s for console and OOB access. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Alan Hannan" To: "NANOG" Sent: Tuesday, September 18, 2018 8:36:33 AM Subject: Console Servers I'd like your input on suggestions for an alternate serial port manager. Long ago I used Cisco 2511/2611 and was fairly happy. A little later I used portmaster and was less so. Recently I've been using Opengear and they work fairly well but the price is fairly high. I use the CM7100 and IM7100. General specs I'm looking for are: * 8 to 48 or more rs232 serial ports on rj45 * nice-to-have software selectable pinouts (cisco v. straight) * gig-e ethernet port (100mbps ok) * 1U form factor * redundant AC power * access physical serial connections via local port # * access physical serial connections via local IP alias (nice to have) Can you recommend a serial port server/concentrator that I could use in place of opengear for a better value and/or lower cost? I'm just ignorant about the current market for serial port concentrators and so far web searches have not revealed ideas, so your input is appreciated! Thanks! -alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahebert at pubnix.net Tue Sep 18 14:01:39 2018 From: ahebert at pubnix.net (Alain Hebert) Date: Tue, 18 Sep 2018 10:01:39 -0400 Subject: Console Servers In-Reply-To: References: Message-ID: What we did (and it fits our needs)     SeaLevel (SeaLink Familly) with a Zotak.     We got both Win/Linux/BSD debugging/monitoring station (with 2 1Gbps, 1 MGMT 1 Mirror) and up to 16 serials ports in 1U.     ( With some DYI )     I'm sure you can get a better density if you check with them. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 09/18/18 09:36, Alan Hannan wrote: > I'd like your input on suggestions for an alternate serial port manager. > > Long ago I used Cisco 2511/2611 and was fairly happy.  A little later > I used portmaster and was less so. Recently I've been using Opengear > and they work fairly well but the price is fairly high.   I use the > CM7100 and IM7100. > > General specs I'm looking for are: > >  * 8 to 48 or more rs232 serial ports on rj45 >  * nice-to-have software selectable pinouts (cisco v. straight) >  * gig-e ethernet port (100mbps ok) >  * 1U form factor >  * redundant AC power >  * access physical serial connections via local port # >  * access physical serial connections via local IP alias (nice to have) > > Can you recommend a serial port server/concentrator that I could use > in place of opengear for a better value and/or lower cost? > > I'm just ignorant about the current market for serial port > concentrators and so far web searches have not revealed ideas, so your > input is appreciated! > > Thanks! > > -alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Tue Sep 18 14:24:04 2018 From: saku at ytti.fi (Saku Ytti) Date: Tue, 18 Sep 2018 17:24:04 +0300 Subject: Console Servers In-Reply-To: References: Message-ID: On Tue, 18 Sep 2018 at 16:39, Alan Hannan wrote: > Long ago I used Cisco 2511/2611 and was fairly happy. A little later I used portmaster and was less so. Recently I've been using Opengear and they work fairly well but the price is fairly high. I use the CM7100 and IM7100. Out of curiosity, how do you connect them? I see quotes around 200USD/MRC for ethernet in US, implying 12kUSD 5 year cost on just connectivity, add rack rental, and power and Opengear price is maybe 10% of TCO? Personally I still prefer Cisco, as not to have new operating system to automate. Add conserver to connect persistently to each console port, so that you get persistent logs from console to your NMS, and so that you can multiplex your console sessions. It's hard to recover the CAPEX benefit if you need OOB platform specific OPEX costs. -- ++ytti From chris.brown at acsalaska.net Tue Sep 18 14:32:17 2018 From: chris.brown at acsalaska.net (Christopher E. Brown) Date: Tue, 18 Sep 2018 06:32:17 -0800 Subject: Console Servers In-Reply-To: <1454495587.5217.1537278546085.JavaMail.mhammett@ThunderFuck> References: <1454495587.5217.1537278546085.JavaMail.mhammett@ThunderFuck> Message-ID: 2811DC or 2811AC NM32 modem module 4 octals 32port RJ45 bulkhead On 9/18/18 05:49, Mike Hammett wrote: > I'm deploying new to me Cisco 2811s for console and OOB access. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ------------------------------------------------------------------------ > *From: *"Alan Hannan" > *To: *"NANOG" > *Sent: *Tuesday, September 18, 2018 8:36:33 AM > *Subject: *Console Servers > > I'd like your input on suggestions for an alternate serial port manager. > > Long ago I used Cisco 2511/2611 and was fairly happy.  A little later I > used portmaster and was less so.  Recently I've been using Opengear and > they work fairly well but the price is fairly high.   I use the CM7100 > and IM7100. > > General specs I'm looking for are: > >  * 8 to 48 or more rs232 serial ports on rj45 >  * nice-to-have software selectable pinouts (cisco v. straight) >  * gig-e ethernet port (100mbps ok) >  * 1U form factor >  * redundant AC power >  * access physical serial connections via local port # >  * access physical serial connections via local IP alias (nice to have) > > Can you recommend a serial port server/concentrator that I could use in > place of opengear for a better value and/or lower cost? > > I'm just ignorant about the current market for serial port concentrators > and so far web searches have not revealed ideas, so your input is > appreciated! > > Thanks! > > -alan > -- ------------------------------------------------------------------------ Christopher E. Brown desk (907) 550-8393 cell (907) 632-8492 IP Engineer - ACS ------------------------------------------------------------------------ From dougm at nist.gov Tue Sep 18 14:47:40 2018 From: dougm at nist.gov (Montgomery, Douglas (Fed)) Date: Tue, 18 Sep 2018 14:47:40 +0000 Subject: [proj-bgp] adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor? In-Reply-To: <17f419236905494fa2000696f23054f6@CRA110.am.necel.com> References: <789C4684-5538-4613-BF37-F1FF810711CA@nist.gov> <17f419236905494fa2000696f23054f6@CRA110.am.necel.com> Message-ID: <72627D8D-8D71-49C7-B593-9E127FFFD5A4@nist.gov> Michel, First, thanks for your continued support as a taxpayer. Second, in general our mission is limited to supporting the development and promulgation of consensus standards and the development of test / measurement methods and guidance to accelerate their adoption. In particular we are not well positioned to provide operational Internet services of the nature you describe. Of course what you describe would not be hard to do if some commercial or other organization wished to do so .... with the following caveats: 1. You should follow the discussion of draft-ietf-sidrops-validating-bgp-speaker which proposed standardizing an approach to doing what you suggest. Many on this thread think that it is a counterproductive idea to do this. See discussion starting here: https://mailarchive.ietf.org/arch/msg/sidrops/6lDz5dI-jg-OhpGR4xKRZ6lYZRA 2. There are some legal issues regarding the redistribution of machine readable RPKI data/results to third parties. See below section 5 Prohibited Conduct: https://www.arin.net/resources/rpki/rpa.pdf What we can do is continue to contribute to the development of standards, produce prototypes and test and measurement tools and publish deployment guidance to help foster adoption. For example see the follow draft publication: https://www.nccoe.nist.gov/projects/building-blocks/secure-inter-domain-routing You mention other suggestions of how we can improve test and measurement services. We welcome all input on that. Maybe contact me off list and we can discuss the other ideas. Thanks, dougm -- Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST On 9/17/18, 11:04 PM, "Michel Py" wrote: Doug, > Montgomery, Douglas wrote : > The new monitor has significant additions in the areas of diagnostics, and highlights issues of > interest such as path / customer cone analysis of prefixes that cover invalid originations. Thanks for all the work. More visibility will help. I have made some private suggestions to how you could enhance the service, and I would add one : provide a BGP feed available to the public with invalid RPKI prefixes with a distinct BGP community describing why the prefix is invalid. We are in an impossible situation where ISPs don't want to discard invalid RPKI prefixes because they can't deal with the customer backshlash of doing it; nothing to gain, money to lose. Money wins. There is another side of this coin, though : you are a government employee. I pay you. As a taxpayer, I think the US governement should provide a better service to US companies with theRPKI collected data. Analysis without action is interesting, but not always federal funding. Best regards, Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From sc at ottie.org Tue Sep 18 08:19:35 2018 From: sc at ottie.org (Scott Christopher) Date: Tue, 18 Sep 2018 08:19:35 +0000 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> <8A48B84A-7284-43D4-826D-108F9E1EF71C@6by7.net> <3d5f160c-c06c-6b13-0588-e1ee2ddacb30@efes.iucc.ac.il> Message-ID: <1537258775.1572455.1511822440.6AE51233@webmail.messagingengine.com> Hank Nussbacher wrote: > On 18/09/2018 08:02, Christopher Morrow wrote: >> >> it's funny/possible that x-connect costs affect where peering appears >> in the landscape, right?> Not this time. Just price gouging since moving a number of cabinets > to a different location is a nightmare. Sure - but at least they have competitors. Look at prices from telecoms like China's CN1. Would you rather have prices set by government-controlled monopolies, or by private competition? --S.C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nusenu-lists at riseup.net Tue Sep 18 11:56:00 2018 From: nusenu-lists at riseup.net (nusenu) Date: Tue, 18 Sep 2018 11:56:00 +0000 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> Message-ID: Dear NANOG, when I approached ARIN about how they feel about reaching out to their members about prefixes that are unreachable in a route origin validation (ROV) environment, John Curran (CEO ARIN) referred me to you (see email bellow - quoted with permission). The question I asked ARIN was specifically: > Would you be open to reach out to your affected members to inform them about > their affected IP prefixes? John Curran (CEO ARIN) wrote: > If there is evidence of community > Interest, then ARIN can conduct a community consultation to determine > our best role in this area, but you first should encourage discussion > within the network operator community at appropriate forums. So here is my question to the network operator community in the ARIN region to gather if there are any (dis)agreements/opinions about such a notification by ARIN: What do you think about the idea that ARIN actively informs their affected members about prefixes that are unreachable in an RPKI ROV environment? The goal of that outreach/notification would be - to reduce the number of broken legacy ROAs from the past - reduce the negative impact on reachability of affected members. looking forward to receiving your feedback! kind regards, nusenu [1] https://medium.com/@nusenu/towards-cleaning-up-rpki-invalids-d69b03ab8a8c John Curran wrote: > Subject: Reaching out to ARIN members about their RPKI INVALID prefixes > > Nusenu - > > Thank you for writing us - the project (and Medium post on same) are > quite interesting. > > I think you’ve got several options for pursuing your objectives, > including – > > 1) Reaching out to parties that already track and report on Internet > routing hygiene (e.g. Geoff Huston at http://bgp.potaroo.net, the > RPKI validator team at RIPE, the NIST RPKI Deployment monitor - > https://rpki-monitor.antd.nist.gov) to see if of them would like to > report on this information and/or contact those with invalids) > > 2) Raising the issue in the ARIN region via the NANOG operator forum > - this would make an excellent lightening talk for you (or someone > else familiar with it already attending) to speak about at the > upcoming NANOG Vancouver meeting. If there is evidence of community > Interest, then ARIN can conduct a community consultation to determine > our best role in this area, but you first should encourage discussion > within the network operator community at appropriate forums. It is > not appropriate for ARIN staff to be proposing this additional role > for the organization, as we within the ARIN staff follow community > direction rather than set it. > > Thanks! /John > > John Curran President and CEO ARIN > -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From cmerritt at verisign.com Tue Sep 18 14:26:39 2018 From: cmerritt at verisign.com (Merritt, Channing) Date: Tue, 18 Sep 2018 14:26:39 +0000 Subject: Console Servers In-Reply-To: <1454495587.5217.1537278546085.JavaMail.mhammett@ThunderFuck> References: <1454495587.5217.1537278546085.JavaMail.mhammett@ThunderFuck> Message-ID: <7c1f005a31ce452480ef71c5e7dbf1ad@verisign.com> Look into OpenGear, we've tested out a couple different products that we've implemented in remote offices to replace our 2800's. From: NANOG On Behalf Of Mike Hammett Sent: Tuesday, September 18, 2018 9:49 AM To: Alan Hannan Cc: NANOG Subject: [EXTERNAL] Re: Console Servers I'm deploying new to me Cisco 2811s for console and OOB access. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP _____ From: "Alan Hannan" > To: "NANOG" > Sent: Tuesday, September 18, 2018 8:36:33 AM Subject: Console Servers I'd like your input on suggestions for an alternate serial port manager. Long ago I used Cisco 2511/2611 and was fairly happy. A little later I used portmaster and was less so. Recently I've been using Opengear and they work fairly well but the price is fairly high. I use the CM7100 and IM7100. General specs I'm looking for are: * 8 to 48 or more rs232 serial ports on rj45 * nice-to-have software selectable pinouts (cisco v. straight) * gig-e ethernet port (100mbps ok) * 1U form factor * redundant AC power * access physical serial connections via local port # * access physical serial connections via local IP alias (nice to have) Can you recommend a serial port server/concentrator that I could use in place of opengear for a better value and/or lower cost? I'm just ignorant about the current market for serial port concentrators and so far web searches have not revealed ideas, so your input is appreciated! Thanks! -alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Tue Sep 18 15:22:51 2018 From: bill at herrin.us (William Herrin) Date: Tue, 18 Sep 2018 11:22:51 -0400 Subject: Console Servers In-Reply-To: <1454495587.5217.1537278546085.JavaMail.mhammett@ThunderFuck> References: <1454495587.5217.1537278546085.JavaMail.mhammett@ThunderFuck> Message-ID: On Tue, Sep 18, 2018 at 9:36 AM, Alan Hannan wrote: > Long ago I used Cisco 2511/2611 and was fairly happy. On Tue, Sep 18, 2018 at 9:49 AM, Mike Hammett wrote: > I'm deploying new to me Cisco 2811s for console and OOB access. > Agree. 2811, 2850s and 3845's are dirt cheap on ebay, the nm-32a's (and HWIC-16a's) work just like you remember in the 2611s and the 2800 series has enough processor and a new enough IOS to handle ssh acceptably. 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 matt at netfire.net Tue Sep 18 15:26:59 2018 From: matt at netfire.net (Matt Harris) Date: Tue, 18 Sep 2018 10:26:59 -0500 Subject: Console Servers In-Reply-To: <7c1f005a31ce452480ef71c5e7dbf1ad@verisign.com> References: <1454495587.5217.1537278546085.JavaMail.mhammett@ThunderFuck> <7c1f005a31ce452480ef71c5e7dbf1ad@verisign.com> Message-ID: I'm a big fan of Raritan's DSX2 gear. Access to serial via ssh or web interface, and the web interface is HTML5, not Java, which is a big advantage if you ever want to use that. I use a bunch of them in production as well and they've been rock solid when I've needed them for managing Cisco, Juniper, Ubiquiti, and other gear via serial. Take care, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From louisk at cryptomonkeys.org Tue Sep 18 15:36:36 2018 From: louisk at cryptomonkeys.org (Louis Kowolowski) Date: Tue, 18 Sep 2018 10:36:36 -0500 Subject: Console Servers In-Reply-To: <7c1f005a31ce452480ef71c5e7dbf1ad@verisign.com> References: <1454495587.5217.1537278546085.JavaMail.mhammett@ThunderFuck> <7c1f005a31ce452480ef71c5e7dbf1ad@verisign.com> Message-ID: <7F0B563A-0F95-4B77-BFF5-DD2DA0C9796C@cryptomonkeys.org> ++ for Opengear. Been happily using them for >10yrs. > On Sep 18, 2018, at 9:26 AM, Merritt, Channing via NANOG wrote: > > Look into OpenGear, we’ve tested out a couple different products that we’ve implemented in remote offices to replace our 2800’s. > > > From: NANOG On Behalf Of Mike Hammett > Sent: Tuesday, September 18, 2018 9:49 AM > To: Alan Hannan > Cc: NANOG > Subject: [EXTERNAL] Re: Console Servers > > I'm deploying new to me Cisco 2811s for console and OOB access. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > From: "Alan Hannan" > To: "NANOG" > Sent: Tuesday, September 18, 2018 8:36:33 AM > Subject: Console Servers > > I'd like your input on suggestions for an alternate serial port manager. > > Long ago I used Cisco 2511/2611 and was fairly happy. A little later I used portmaster and was less so. Recently I've been using Opengear and they work fairly well but the price is fairly high. I use the CM7100 and IM7100. > > General specs I'm looking for are: > > * 8 to 48 or more rs232 serial ports on rj45 > * nice-to-have software selectable pinouts (cisco v. straight) > * gig-e ethernet port (100mbps ok) > * 1U form factor > * redundant AC power > * access physical serial connections via local port # > * access physical serial connections via local IP alias (nice to have) > > Can you recommend a serial port server/concentrator that I could use in place of opengear for a better value and/or lower cost? > > I'm just ignorant about the current market for serial port concentrators and so far web searches have not revealed ideas, so your input is appreciated! > > Thanks! > > -alan -- Louis Kowolowski louisk at cryptomonkeys.org Cryptomonkeys: http://www.cryptomonkeys.com/ Making life more interesting for people since 1977 From lathama at gmail.com Tue Sep 18 15:43:07 2018 From: lathama at gmail.com (Andrew Latham) Date: Tue, 18 Sep 2018 10:43:07 -0500 Subject: Console Servers In-Reply-To: References: Message-ID: Alan There are maybe too many options out there. The used Cyclades are the lowest cost entry point. An ideal solution might be https://freetserv.github.io/ but some assembly required. I have Lantronix OOB solutions in my lab. Most modern servers come with some SOL options so I will assume this is for networking equipment. The modern HTML5 interfaces are great and really do drop all the legacy Java requirements. On Tue, Sep 18, 2018 at 8:38 AM Alan Hannan wrote: > I'd like your input on suggestions for an alternate serial port manager. > > Long ago I used Cisco 2511/2611 and was fairly happy. A little later I > used portmaster and was less so. Recently I've been using Opengear and > they work fairly well but the price is fairly high. I use the CM7100 and > IM7100. > > General specs I'm looking for are: > > * 8 to 48 or more rs232 serial ports on rj45 > * nice-to-have software selectable pinouts (cisco v. straight) > * gig-e ethernet port (100mbps ok) > * 1U form factor > * redundant AC power > * access physical serial connections via local port # > * access physical serial connections via local IP alias (nice to have) > > Can you recommend a serial port server/concentrator that I could use in > place of opengear for a better value and/or lower cost? > > I'm just ignorant about the current market for serial port concentrators > and so far web searches have not revealed ideas, so your input is > appreciated! > > Thanks! > > -alan > -- - Andrew "lathama" Latham - -------------- next part -------------- An HTML attachment was scrubbed... URL: From pozar at lns.com Tue Sep 18 15:48:42 2018 From: pozar at lns.com (Tim Pozar) Date: Tue, 18 Sep 2018 08:48:42 -0700 Subject: Console Servers In-Reply-To: References: Message-ID: <2990c89a-5064-2e91-0a6a-0a2f8b5fc06b@lns.com> I have been deploying Cyclades TS3000 boxes that I can sometimes find for about $75 each on eBay. The down side is the firmware is a bit old so the SSH daemon doesn't really support current ciphers. The other downside is the CLI ia a bit cumbersome. Tim On 9/18/18 8:43 AM, Andrew Latham wrote: > Alan > > There are maybe too many options out there. The used Cyclades are the > lowest cost entry point. An ideal solution might > be https://freetserv.github.io/ but some assembly required. I have > Lantronix OOB solutions in my lab. Most modern servers come with some > SOL options so I will assume this is for networking equipment. The > modern HTML5 interfaces are great and really do drop all the legacy Java > requirements. > > On Tue, Sep 18, 2018 at 8:38 AM Alan Hannan > wrote: > > I'd like your input on suggestions for an alternate serial port manager. > > Long ago I used Cisco 2511/2611 and was fairly happy.  A little > later I used portmaster and was less so.  Recently I've been using > Opengear and they work fairly well but the price is fairly high.   I > use the CM7100 and IM7100. > > General specs I'm looking for are: > >  * 8 to 48 or more rs232 serial ports on rj45 >  * nice-to-have software selectable pinouts (cisco v. straight) >  * gig-e ethernet port (100mbps ok) >  * 1U form factor >  * redundant AC power >  * access physical serial connections via local port # >  * access physical serial connections via local IP alias (nice to have) > > Can you recommend a serial port server/concentrator that I could use > in place of opengear for a better value and/or lower cost? > > I'm just ignorant about the current market for serial port > concentrators and so far web searches have not revealed ideas, so > your input is appreciated! > > Thanks! > > -alan > > > > -- > - Andrew "lathama" Latham - From skhosla at neutraldata.com Tue Sep 18 15:52:55 2018 From: skhosla at neutraldata.com (Sameer Khosla) Date: Tue, 18 Sep 2018 15:52:55 +0000 Subject: Console Servers In-Reply-To: References: Message-ID: <49A81EB09F493442B6D259E36251192C03CEEF7882@ndcc-exch1.neutraldata.com> My favorite are the lantronix SLC console servers. Fairly bullet-proof, they are one of those devices that just work. Can usually be picked up used ~$300 for 32 or 48 port varieties in good condition if you aren’t in the biggest hurry. Sk. From: NANOG On Behalf Of Alan Hannan Sent: Tuesday, September 18, 2018 9:37 AM To: NANOG Subject: Console Servers I'd like your input on suggestions for an alternate serial port manager. Long ago I used Cisco 2511/2611 and was fairly happy. A little later I used portmaster and was less so. Recently I've been using Opengear and they work fairly well but the price is fairly high. I use the CM7100 and IM7100. General specs I'm looking for are: * 8 to 48 or more rs232 serial ports on rj45 * nice-to-have software selectable pinouts (cisco v. straight) * gig-e ethernet port (100mbps ok) * 1U form factor * redundant AC power * access physical serial connections via local port # * access physical serial connections via local IP alias (nice to have) Can you recommend a serial port server/concentrator that I could use in place of opengear for a better value and/or lower cost? I'm just ignorant about the current market for serial port concentrators and so far web searches have not revealed ideas, so your input is appreciated! Thanks! -alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brandon at rd.bbc.co.uk Tue Sep 18 15:59:00 2018 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Tue, 18 Sep 2018 16:59:00 +0100 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: <1537258775.1572455.1511822440.6AE51233@webmail.messagingengine.com> References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> <8A48B84A-7284-43D4-826D-108F9E1EF71C@6by7.net> <3d5f160c-c06c-6b13-0588-e1ee2ddacb30@efes.iucc.ac.il> <1537258775.1572455.1511822440.6AE51233@webmail.messagingengine.com> Message-ID: <20180918155859.GA12055@sunf10.rd.bbc.co.uk> On Tue Sep 18, 2018 at 08:19:35AM +0000, Scott Christopher wrote: > Hank Nussbacher wrote: > > > On 18/09/2018 08:02, Christopher Morrow wrote: > >> > >> it's funny/possible that x-connect costs affect where peering appears > >> in the landscape, right?> Not this time. Just price gouging since moving a number of cabinets > > to a different location is a nightmare. > Sure - but at least they have competitors. > > Look at prices from telecoms like China's CN1. Would you rather have > prices set by government-controlled monopolies, or by private > competition? > --S.C. It's more like a loose cartel with some leading to see how far they can push it and the rest following in step. As long as they don't go too fast nobody will see a large enough difference to be worth changing location. Equinix were a leader in bringing this to the UK, they have said they want to get the UK charges to US levels (so >10x increase still to come). US pricing already matches metro waves so we face paying twice the cost of the wave to the DCs for the short interconnects. Telehouse (UK) was one of the good ones with no MRC, the risers got full due to the popularity of no MRCs (they sold out of rack space repeatedly too). They started charging but I can't attribute the growing empty rack space to that, more likely AWS is the cause of that and a driver for increasing xcon fees to make up revenue. brandon From morrowc.lists at gmail.com Tue Sep 18 16:04:28 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 18 Sep 2018 09:04:28 -0700 Subject: Console Servers In-Reply-To: <49A81EB09F493442B6D259E36251192C03CEEF7882@ndcc-exch1.neutraldata.com> References: <49A81EB09F493442B6D259E36251192C03CEEF7882@ndcc-exch1.neutraldata.com> Message-ID: a vote for (so far so good) the nodegrid ZPE devices. On Tue, Sep 18, 2018 at 8:54 AM Sameer Khosla wrote: > My favorite are the lantronix SLC console servers. Fairly bullet-proof, > they are one of those devices that just work. Can usually be picked up > used ~$300 for 32 or 48 port varieties in good condition if you aren’t in > the biggest hurry. > > > > Sk. > > > > > > *From:* NANOG *On Behalf Of *Alan Hannan > *Sent:* Tuesday, September 18, 2018 9:37 AM > *To:* NANOG > *Subject:* Console Servers > > > > I'd like your input on suggestions for an alternate serial port manager. > > > > Long ago I used Cisco 2511/2611 and was fairly happy. A little later I > used portmaster and was less so. Recently I've been using Opengear and > they work fairly well but the price is fairly high. I use the CM7100 and > IM7100. > > > > General specs I'm looking for are: > > > > * 8 to 48 or more rs232 serial ports on rj45 > > * nice-to-have software selectable pinouts (cisco v. straight) > > * gig-e ethernet port (100mbps ok) > > * 1U form factor > > * redundant AC power > > * access physical serial connections via local port # > > * access physical serial connections via local IP alias (nice to have) > > > > Can you recommend a serial port server/concentrator that I could use in > place of opengear for a better value and/or lower cost? > > > > I'm just ignorant about the current market for serial port concentrators > and so far web searches have not revealed ideas, so your input is > appreciated! > > > > Thanks! > > > > -alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhuff at ox.com Tue Sep 18 16:13:51 2018 From: mhuff at ox.com (Matthew Huff) Date: Tue, 18 Sep 2018 16:13:51 +0000 Subject: Console Servers In-Reply-To: References: <49A81EB09F493442B6D259E36251192C03CEEF7882@ndcc-exch1.neutraldata.com> Message-ID: <476add9fc0ca4c4fbf7f2333cab1ba0a@ox.com> If anyone is looking for a product that is reasonably priced and is still being produced/update, the ADVA Optical (aka MRV, aka Xyplex) console servers still work great https://www.advaoptical.com/en/products/network-infrastructure-assurance/lx-series From their specs: 4, 8, 16, 32 and 48 serial ports V.92 modem option Single or dual power 120-240VAC, 50/60Hz: 0.5A per system 36-72VDC dual feed: 0.75A per system 2 x Ethernet NEBS Level 3 certified From Ryan.Hamel at quadranet.com Tue Sep 18 16:16:56 2018 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Tue, 18 Sep 2018 16:16:56 +0000 Subject: Console Servers In-Reply-To: References: <49A81EB09F493442B6D259E36251192C03CEEF7882@ndcc-exch1.neutraldata.com> Message-ID: <0123cdeb09d94da099bcdfea9b5b67e5@MIA-MBX01.quadranet.local> I just use a Raspberry Pi with USB to Serial adapters or old servers with PCI(-E) 8 port serial cards. They make it so easy to adapt to any environment, and it phones home to my conserver (https://www.conserver.com/) gateway. The total cost for hardware is less than $150. Ryan From: NANOG On Behalf Of Christopher Morrow Sent: Tuesday, September 18, 2018 9:04 AM To: Sameer Khosla Cc: nanog list Subject: Re: Console Servers a vote for (so far so good) the nodegrid ZPE devices. On Tue, Sep 18, 2018 at 8:54 AM Sameer Khosla > wrote: My favorite are the lantronix SLC console servers. Fairly bullet-proof, they are one of those devices that just work. Can usually be picked up used ~$300 for 32 or 48 port varieties in good condition if you aren’t in the biggest hurry. Sk. From: NANOG > On Behalf Of Alan Hannan Sent: Tuesday, September 18, 2018 9:37 AM To: NANOG > Subject: Console Servers I'd like your input on suggestions for an alternate serial port manager. Long ago I used Cisco 2511/2611 and was fairly happy. A little later I used portmaster and was less so. Recently I've been using Opengear and they work fairly well but the price is fairly high. I use the CM7100 and IM7100. General specs I'm looking for are: * 8 to 48 or more rs232 serial ports on rj45 * nice-to-have software selectable pinouts (cisco v. straight) * gig-e ethernet port (100mbps ok) * 1U form factor * redundant AC power * access physical serial connections via local port # * access physical serial connections via local IP alias (nice to have) Can you recommend a serial port server/concentrator that I could use in place of opengear for a better value and/or lower cost? I'm just ignorant about the current market for serial port concentrators and so far web searches have not revealed ideas, so your input is appreciated! Thanks! -alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Sep 18 17:23:42 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Sep 2018 10:23:42 -0700 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> Message-ID: <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> Personally, since all RPKI accomplishes is providing a cryptographically signed notation of origin ASNs that hijackers should prepend to their announcements in order to create an aura of credibility, I think we should stop throwing resources down this rathole. Owen > On Sep 18, 2018, at 4:56 AM, nusenu wrote: > > Dear NANOG, > > when I approached ARIN about how they feel about reaching out to their members about > prefixes that are unreachable in a route origin validation (ROV) environment, > John Curran (CEO ARIN) referred me to you (see email bellow - quoted with permission). > > The question I asked ARIN was specifically: >> Would you be open to reach out to your affected members to inform them about >> their affected IP prefixes? > > John Curran (CEO ARIN) wrote: >> If there is evidence of community >> Interest, then ARIN can conduct a community consultation to determine >> our best role in this area, but you first should encourage discussion >> within the network operator community at appropriate forums. > > So here is my question to the network operator community in the ARIN region to > gather if there are any (dis)agreements/opinions about such a notification by ARIN: > > What do you think about the idea that ARIN actively informs their affected members > about prefixes that are unreachable in an RPKI ROV environment? > > The goal of that outreach/notification would be > - to reduce the number of broken legacy ROAs from the past > - reduce the negative impact on reachability of affected members. > > looking forward to receiving your feedback! > > kind regards, > nusenu > > > > > [1] https://medium.com/@nusenu/towards-cleaning-up-rpki-invalids-d69b03ab8a8c > > John Curran wrote: >> Subject: Reaching out to ARIN members about their RPKI INVALID prefixes >> >> Nusenu - >> >> Thank you for writing us - the project (and Medium post on same) are >> quite interesting. >> >> I think you’ve got several options for pursuing your objectives, >> including – >> >> 1) Reaching out to parties that already track and report on Internet >> routing hygiene (e.g. Geoff Huston at http://bgp.potaroo.net, the >> RPKI validator team at RIPE, the NIST RPKI Deployment monitor - >> https://rpki-monitor.antd.nist.gov) to see if of them would like to >> report on this information and/or contact those with invalids) >> >> 2) Raising the issue in the ARIN region via the NANOG operator forum >> - this would make an excellent lightening talk for you (or someone >> else familiar with it already attending) to speak about at the >> upcoming NANOG Vancouver meeting. If there is evidence of community >> Interest, then ARIN can conduct a community consultation to determine >> our best role in this area, but you first should encourage discussion >> within the network operator community at appropriate forums. It is >> not appropriate for ARIN staff to be proposing this additional role >> for the organization, as we within the ARIN staff follow community >> direction rather than set it. >> >> Thanks! /John >> >> John Curran President and CEO ARIN >> > > > > -- > https://twitter.com/nusenu_ > https://mastodon.social/@nusenu > From job at ntt.net Tue Sep 18 17:35:42 2018 From: job at ntt.net (Job Snijders) Date: Tue, 18 Sep 2018 17:35:42 +0000 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> Message-ID: <20180918173542.GE58800@vurt.meerval.net> Owen, On Tue, Sep 18, 2018 at 10:23:42AM -0700, Owen DeLong wrote: > Personally, since all RPKI accomplishes is providing a > cryptographically signed notation of origin ASNs that hijackers should > prepend to their announcements in order to create an aura of > credibility, I think we should stop throwing resources down this > rathole. 1/ You may be overlooking the fact that many networks peer directly with what (for them) are the important sources/destinations. The semantics of RPKI ROAs help block illegitimate more-specifics, and the short AS_PATH between players prevents a hijacker from inserting themself. In other words - the most important AS_PATHs are 1 hop. The Internet's dense interconnectedness is saving its bacon. 2/ Another approach to achieve path validation for 1 hop is through mechanisms such what NTT calls 'peerlock'. https://www.youtube.com/watch?v=CSLpWBrHy10 3/ Lastly, some folks are innovating in this space to help automate concepts such as peerlock through what is called ASPA. ASPA is intended as an out-of-band, deployable alternative to BGPSec. https://tools.ietf.org/html/draft-azimov-sidrops-aspa-profile https://tools.ietf.org/html/draft-azimov-sidrops-aspa-verification I think you underestimate how valuable RPKI based Origin Validation (even just by itself) is in today's Internet landscape. If you are aware of other efforts or more fruitful approaches please let us know. Kind regards, Job From morrowc.lists at gmail.com Tue Sep 18 18:06:48 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 18 Sep 2018 11:06:48 -0700 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: <20180918173542.GE58800@vurt.meerval.net> References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180918173542.GE58800@vurt.meerval.net> Message-ID: On Tue, Sep 18, 2018 at 10:36 AM Job Snijders wrote: > Owen, > > On Tue, Sep 18, 2018 at 10:23:42AM -0700, Owen DeLong wrote: > > Personally, since all RPKI accomplishes is providing a > > cryptographically signed notation of origin ASNs that hijackers should > > prepend to their announcements in order to create an aura of > > credibility, I think we should stop throwing resources down this > > rathole. > I think you underestimate how valuable RPKI based Origin Validation > (even just by itself) is in today's Internet landscape. > > If you are aware of other efforts or more fruitful approaches please let > us know. > > Perhaps said another way: "How would you figure out what prefixes your bgp peer(s) should be sending you?" (in an automatable, and verifiable manner) -chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Tue Sep 18 18:16:06 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 18 Sep 2018 11:16:06 -0700 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> Message-ID: (popping back to the top of the thread.. sorry) On Tue, Sep 18, 2018 at 7:58 AM nusenu wrote: > Dear NANOG, > > when I approached ARIN about how they feel about reaching out to their > members about > prefixes that are unreachable in a route origin validation (ROV) > environment, > John Curran (CEO ARIN) referred me to you (see email bellow - quoted with > permission). > > Perhaps this was answered elsewhere, but: "Why is this something ARIN (the org) should take on?" Why can't (or why isn't) this something that 'many' monitoring/alerting companies/orgs are offering? it's unclear, to me, why ARIN is in any better position than any other party to perform this sort of activity? I would expect that, at the base level, "I just got random/unexpected email from ARIN?" will get dropped in the spam-can, while: "My monitoring company to which I signed up/contracted emailed into my ticket-system for action.. better go do something!" is the path to incentivize. The question I asked ARIN was specifically: > > Would you be open to reach out to your affected members to inform them > about > > their affected IP prefixes? > > 'how?' (email to the tech-contact? etc? did they sign up for said monitoring and point to the right destination email catcher?) -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Sep 18 18:35:07 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Sep 2018 11:35:07 -0700 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: <3d5f160c-c06c-6b13-0588-e1ee2ddacb30@efes.iucc.ac.il> References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> <8A48B84A-7284-43D4-826D-108F9E1EF71C@6by7.net> <3d5f160c-c06c-6b13-0588-e1ee2ddacb30@efes.iucc.ac.il> Message-ID: <08651119-3714-4A53-ADF0-989869253BE9@delong.com> > On Sep 17, 2018, at 9:42 PM, Hank Nussbacher wrote: > > On 17/09/2018 23:26, Phil Lavin wrote: >>> $350/mo seems to be standard. Our DCs are at $250. Seems more like they held onto out of date pricing for a long time then realized it. >> For what it's worth, Telehouse London is around 30 USD/month for an x-connect within the same building. Our US datacentre (not Telehouse) on the other hand is around 200 USD/month. It's always felt disproportionally expensive but maybe those kind of prices are expected for the North America region. > Current list price for 10G Xconnect at the major colo site in Israel is > $5840/month. Discounts are available :-) > Keep complaining about $350/mo costs. You have no idea how lucky you are. > > -Hank So, you’re arguing that because the prices in Israel are 15*ridiculous, we should stop complaining about 1*ridiculous? You have no idea how distorted your perspective is. Owen From bhm at ufl.edu Tue Sep 18 19:02:50 2018 From: bhm at ufl.edu (Bruce H McIntosh) Date: Tue, 18 Sep 2018 15:02:50 -0400 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: <08651119-3714-4A53-ADF0-989869253BE9@delong.com> References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> <8A48B84A-7284-43D4-826D-108F9E1EF71C@6by7.net> <3d5f160c-c06c-6b13-0588-e1ee2ddacb30@efes.iucc.ac.il> <08651119-3714-4A53-ADF0-989869253BE9@delong.com> Message-ID: >> Current list price for 10G Xconnect at the major colo site in Israel is >> $5840/month. Discounts are available :-) >> Keep complaining about $350/mo costs. You have no idea how lucky you are. >> >> -Hank > > So, you’re arguing that because the prices in Israel are 15*ridiculous, we should stop complaining about 1*ridiculous? > > You have no idea how distorted your perspective is. It's not necessarily distorted, it's just a different frame of reference. I can remember a conversation like this at a Joint Techs meeting many years back. Several of us were outgassing about how expensive it was to get 100mbps connections off our campuses, until the guy from the University of Hawaii told us how much he was paying per month for a *T1* to the mainland. :D -- -------------------------------------------- Bruce H. McIntosh Network Engineer II University of Florida Information Technology bhm at ufl.edu 352-273-1066 From owen at delong.com Tue Sep 18 19:04:19 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Sep 2018 12:04:19 -0700 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180918173542.GE58800@vurt.meerval.net> Message-ID: <94EBD5EC-F723-45BC-A6AD-10895E2B8C0E@delong.com> > On Sep 18, 2018, at 11:06 AM, Christopher Morrow wrote: > > > > On Tue, Sep 18, 2018 at 10:36 AM Job Snijders > wrote: > Owen, > > On Tue, Sep 18, 2018 at 10:23:42AM -0700, Owen DeLong wrote: > > Personally, since all RPKI accomplishes is providing a > > cryptographically signed notation of origin ASNs that hijackers should > > prepend to their announcements in order to create an aura of > > credibility, I think we should stop throwing resources down this > > rathole. > I think you underestimate how valuable RPKI based Origin Validation > (even just by itself) is in today's Internet landscape. > > If you are aware of other efforts or more fruitful approaches please let > us know. > > > Perhaps said another way: > > "How would you figure out what prefixes your bgp peer(s) should be sending you?" > (in an automatable, and verifiable manner) > > -chris In theory, that’s what IRRs are for. In practice, while they offer better theoretical capabilities if stronger authentication were added, the current implementation and acceptance leaves much to be desired. However, even in theory, RPKI offers nothing of particular benefit even in its best case of widespread implementation. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Sep 18 19:08:34 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Sep 2018 12:08:34 -0700 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: <20180918173542.GE58800@vurt.meerval.net> References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180918173542.GE58800@vurt.meerval.net> Message-ID: > On Sep 18, 2018, at 10:35 AM, Job Snijders wrote: > > Owen, > > On Tue, Sep 18, 2018 at 10:23:42AM -0700, Owen DeLong wrote: >> Personally, since all RPKI accomplishes is providing a >> cryptographically signed notation of origin ASNs that hijackers should >> prepend to their announcements in order to create an aura of >> credibility, I think we should stop throwing resources down this >> rathole. > > 1/ You may be overlooking the fact that many networks peer directly with > what (for them) are the important sources/destinations. The semantics of > RPKI ROAs help block illegitimate more-specifics, and the short AS_PATH > between players prevents a hijacker from inserting themself. In other > words - the most important AS_PATHs are 1 hop. The Internet's dense > interconnectedness is saving its bacon. While this may be true for a handful of well peered ASNs, it’s certainly not common around the wider internet. > 2/ Another approach to achieve path validation for 1 hop is through > mechanisms such what NTT calls 'peerlock'. > https://www.youtube.com/watch?v=CSLpWBrHy10 Single hop is relatively easy. It’s 2+ hop where things get far more interesting. It’s convenient to reduce the problem set to the one you can easily solve, but ignoring the rest of the problem set smacks of hand-waving and “insert magic here”. > 3/ Lastly, some folks are innovating in this space to help automate > concepts such as peerlock through what is called ASPA. ASPA is intended > as an out-of-band, deployable alternative to BGPSec. OK, but IIRC, it’s rather orthogonal to RPKI. > https://tools.ietf.org/html/draft-azimov-sidrops-aspa-profile > https://tools.ietf.org/html/draft-azimov-sidrops-aspa-verification > > I think you underestimate how valuable RPKI based Origin Validation > (even just by itself) is in today's Internet landscape. I think you overestimate it. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Tue Sep 18 19:09:37 2018 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 18 Sep 2018 15:09:37 -0400 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: <94EBD5EC-F723-45BC-A6AD-10895E2B8C0E@delong.com> References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180918173542.GE58800@vurt.meerval.net> <94EBD5EC-F723-45BC-A6AD-10895E2B8C0E@delong.com> Message-ID: > On Sep 18, 2018, at 3:04 PM, Owen DeLong wrote: > > > >> On Sep 18, 2018, at 11:06 AM, Christopher Morrow wrote: >> >> >> >> On Tue, Sep 18, 2018 at 10:36 AM Job Snijders wrote: >> Owen, >> >> On Tue, Sep 18, 2018 at 10:23:42AM -0700, Owen DeLong wrote: >> > Personally, since all RPKI accomplishes is providing a >> > cryptographically signed notation of origin ASNs that hijackers should >> > prepend to their announcements in order to create an aura of >> > credibility, I think we should stop throwing resources down this >> > rathole. >> I think you underestimate how valuable RPKI based Origin Validation >> (even just by itself) is in today's Internet landscape. >> >> If you are aware of other efforts or more fruitful approaches please let >> us know. >> >> >> Perhaps said another way: >> >> "How would you figure out what prefixes your bgp peer(s) should be sending you?" >> (in an automatable, and verifiable manner) >> >> -chris > > In theory, that’s what IRRs are for. > > In practice, while they offer better theoretical capabilities if stronger authentication were added, the current implementation and acceptance leaves much to be desired. Judging a global ecosystem just by what ARIN does is perhaps some of the issue. ARIN seems to be the outlier here as has been measured. An ARIN prefix ROA is less valuable than the other regions and this is IMO deliberate on the part of ARIN. > However, even in theory, RPKI offers nothing of particular benefit even in its best case of widespread implementation. Disagree, but that’s ok. I know at $dayJob I’m preparing the way, but it’s much harder than it should be due to the nature of our business. - Jared From owen at delong.com Tue Sep 18 19:26:53 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Sep 2018 12:26:53 -0700 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> <8A48B84A-7284-43D4-826D-108F9E1EF71C@6by7.net> <3d5f160c-c06c-6b13-0588-e1ee2ddacb30@efes.iucc.ac.il> <08651119-3714-4A53-ADF0-989869253BE9@delong.com> Message-ID: <0D56BF2A-A5F2-4FC5-9E66-F8733AA2BADF@delong.com> > On Sep 18, 2018, at 12:02 PM, Bruce H McIntosh wrote: > >>> Current list price for 10G Xconnect at the major colo site in Israel is >>> $5840/month. Discounts are available :-) >>> Keep complaining about $350/mo costs. You have no idea how lucky you are. >>> >>> -Hank >> So, you’re arguing that because the prices in Israel are 15*ridiculous, we should stop complaining about 1*ridiculous? >> You have no idea how distorted your perspective is. > > It's not necessarily distorted, it's just a different frame of reference. I can remember a conversation like this at a Joint Techs meeting many years back. Several of us were outgassing about how expensive it was to get 100mbps connections off our campuses, until the guy from the University of Hawaii told us how much he was paying per month for a *T1* to the mainland. :D Sure, but in this case, we’re not comparing transaoceanic circuits to local loops, we’re comparing single pair fiber cross connects between two points in the same datacenter or datacenter campus. I’d argue that the difference between reasonable (≤$500 one-time and ≤$50 MRC) and $300 MRC is within range of argument, but I cannot see any way in which an argument can be made that $5840 MRC is not a distortion in that same circumstance. Owen From surfer at mauigateway.com Tue Sep 18 19:55:38 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 18 Sep 2018 12:55:38 -0700 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC Message-ID: <20180918125538.B1EBE47B@m0117567.ppops.net> --- bhm at ufl.edu wrote: From: Bruce H McIntosh I can remember a conversation like this at a Joint Techs meeting many years back. Several of us were outgassing about how expensive it was to get 100mbps connections off our campuses, until the guy from the University of Hawaii told us how much he was paying per month for a *T1* to the mainland. :D ------------------------------------------- That was many, many (ancient) years back! :-) scott From nusenu-lists at riseup.net Tue Sep 18 20:33:00 2018 From: nusenu-lists at riseup.net (nusenu) Date: Tue, 18 Sep 2018 20:33:00 +0000 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> Message-ID: Christopher Morrow wrote: > Perhaps this was answered elsewhere, but: "Why is this something > ARIN (the org) should take on?" Thanks for this question, I believe this is an important one. I reasoned about why I think RIRs are in a good position to send these emails here: [1] but I will quote from it for convenience: > Notifying affected IP Holders > > The natural next step (and that was our initial intention when > looking at INVALIDs) would be to send out emails to affected IP > holders and ask them to address the INVALIDs but although that could > be automated, we believe the impact would be better, if that email > came from some trusted entity like the RIR relevant to the affected > IP holder instead of a random entity they never had any contact > before (us). > > Asking RIRs to reach out to their members also scales better since > every RIR would only have to take care of their own members. [...] [1] https://medium.com/@nusenu/towards-cleaning-up-rpki-invalids-d69b03ab8a8c > Why can't (or why isn't) this something that 'many' > monitoring/alerting companies/orgs are offering? There are companies offering BGP monitoring including RPKI ROAs, but the affected IP holders are unlikely customers of those monitoring services or generally aware of the problem. > it's unclear, to me, why ARIN is in any better position than any > other party to perform this sort of activity? I would expect that, at > the base level, "I just got random/unexpected email from ARIN?" will > get dropped in the spam-can, while: "My monitoring company to which I > signed up/contracted emailed into my ticket-system for action.. > better go do something!" is the path to incentivize. The problem is how do you make operators aware of the problem in the first place. > The question I asked ARIN was specifically: >>> Would you be open to reach out to your affected members to >>> inform them about their affected IP prefixes? >> >> > 'how?' (email to the tech-contact? etc? did they sign up for said > monitoring and point to the right destination email catcher?) Yes that is what I had in mind (notification via email to the tech contact). kind regards, nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From michel.py at tsisemi.com Tue Sep 18 20:45:45 2018 From: michel.py at tsisemi.com (Michel Py) Date: Tue, 18 Sep 2018 20:45:45 +0000 Subject: [proj-bgp] adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor? In-Reply-To: <72627D8D-8D71-49C7-B593-9E127FFFD5A4@nist.gov> References: <789C4684-5538-4613-BF37-F1FF810711CA@nist.gov> <17f419236905494fa2000696f23054f6@CRA110.am.necel.com> <72627D8D-8D71-49C7-B593-9E127FFFD5A4@nist.gov> Message-ID: Doug, > Douglas Montgomery wrote : > You should follow the discussion of draft-ietf-sidrops-validating-bgp-speaker which proposed standardizing an approach to doing > what you suggest. Many on this thread think that it is a counterproductive idea to do this. See discussion starting here: > https://mailarchive.ietf.org/arch/msg/sidrops/6lDz5dI-jg-OhpGR4xKRZ6lYZRA I'm looking at adoption numbers, especially in the ARIN region. RPKI is practically inexistant, and some respected members are already saying it's a rathole. At 2% deployment, we are far away from the critical mass it needs. If the deployment strategy does not change, I don't see how that critical mass will happen. Until someone actually starts to discard invalid RPKI prefixes and assesses the actual inconvenience, this is not going anywhere. If you want to promote it, you have to do something not just analyze. > Second, in general our mission is limited to supporting the development and promulgation of consensus standards and the development of test / measurement methods > and guidanceto accelerate their adoption. In particular we are not well positioned to provide operational Internet services of the nature you describe. You provide critical time services, this would be nothing compared to it. > 2. There are some legal issues regarding the redistribution of machine readable RPKI data/results to third parties. See below section 5 Prohibited Conduct: > https://www.arin.net/resources/rpki/rpa.pdf As always (and rightfully so) ARIN is trying to avoid legal liability. Better to remove the possibility of getting sued than having to deal with it. There are ways around that. My $0.02, Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From michel.py at tsisemi.com Tue Sep 18 20:51:59 2018 From: michel.py at tsisemi.com (Michel Py) Date: Tue, 18 Sep 2018 20:51:59 +0000 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> Message-ID: <4f72dfea2ead4ab1980d18c98f092d1a@CRA110.am.necel.com> > nusenu wrote : > What do you think about the idea that ARIN actively informs their affected members about prefixes that are unreachable in an RPKI ROV environment? Support, although I doubt it would achieve the desired result. I support it for the following reason : when someone starts to block invalid prefixes, they would not have the excuse to say "we did not know about it". Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From morrowc.lists at gmail.com Tue Sep 18 21:15:33 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 18 Sep 2018 14:15:33 -0700 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> Message-ID: On Tue, Sep 18, 2018 at 1:33 PM nusenu wrote: > Christopher Morrow wrote: > > Perhaps this was answered elsewhere, but: "Why is this something > > ARIN (the org) should take on?" > > Thanks for this question, I believe this is an important one. > > I reasoned about why I think RIRs are in a good position to send these > emails here: [1] > but I will quote from it for convenience: > > > Notifying affected IP Holders > > > > The natural next step (and that was our initial intention when > > looking at INVALIDs) would be to send out emails to affected IP > > holders and ask them to address the INVALIDs but although that could > > be automated, we believe the impact would be better, if that email > > came from some trusted entity like the RIR relevant to the affected > > IP holder instead of a random entity they never had any contact > > before (us). > > > > Asking RIRs to reach out to their members also scales better since > > every RIR would only have to take care of their own members. > [...] > > i don't know that the contacts the RIR has for the entity is necessarily the one that controls/deals-with the RPKI data though. I also think that generally if folk set all that up they probably know (or will soon enough) that they have a mistake. Generally speaking, I think "folk should fix themselves, and maintain/monitor their configuration", that ARIN (or anyone else sending 'unsolicited email') here is going to end badly in the worst case and 'not have any effect' in the majority of cases. > [1] > https://medium.com/@nusenu/towards-cleaning-up-rpki-invalids-d69b03ab8a8c > > > > Why can't (or why isn't) this something that 'many' > > monitoring/alerting companies/orgs are offering? > > There are companies offering BGP monitoring including RPKI ROAs, but > the affected IP holders are unlikely customers of those monitoring > services or generally aware of the problem. > > ok, maybe they should though? :) > > it's unclear, to me, why ARIN is in any better position than any > > other party to perform this sort of activity? I would expect that, at > > the base level, "I just got random/unexpected email from ARIN?" will > > get dropped in the spam-can, while: "My monitoring company to which I > > signed up/contracted emailed into my ticket-system for action.. > > better go do something!" is the path to incentivize. > > The problem is how do you make operators aware of the problem in the first > place. > > ideally they are aware of thier own config, have a person(s) responsible for managing that configuration and care about reachability... if they don't have that today, they will soon enough. > > The question I asked ARIN was specifically: > >>> Would you be open to reach out to your affected members to > >>> inform them about their affected IP prefixes? > >> > >> > > 'how?' (email to the tech-contact? etc? did they sign up for said > > monitoring and point to the right destination email catcher?) > > Yes that is what I had in mind (notification via email to the tech > contact). > > i'm positive that will end in sadness. > kind regards, > nusenu > > -- > https://twitter.com/nusenu_ > https://mastodon.social/@nusenu > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Sep 18 21:18:55 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Sep 2018 14:18:55 -0700 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180918173542.GE58800@vurt.meerval.net> <94EBD5EC-F723-45BC-A6AD-10895E2B8C0E@delong.com> Message-ID: > On Sep 18, 2018, at 12:09 PM, Jared Mauch wrote: > > > >> On Sep 18, 2018, at 3:04 PM, Owen DeLong wrote: >> >> >> >>> On Sep 18, 2018, at 11:06 AM, Christopher Morrow wrote: >>> >>> >>> >>> On Tue, Sep 18, 2018 at 10:36 AM Job Snijders wrote: >>> Owen, >>> >>> On Tue, Sep 18, 2018 at 10:23:42AM -0700, Owen DeLong wrote: >>>> Personally, since all RPKI accomplishes is providing a >>>> cryptographically signed notation of origin ASNs that hijackers should >>>> prepend to their announcements in order to create an aura of >>>> credibility, I think we should stop throwing resources down this >>>> rathole. >>> I think you underestimate how valuable RPKI based Origin Validation >>> (even just by itself) is in today's Internet landscape. >>> >>> If you are aware of other efforts or more fruitful approaches please let >>> us know. >>> >>> >>> Perhaps said another way: >>> >>> "How would you figure out what prefixes your bgp peer(s) should be sending you?" >>> (in an automatable, and verifiable manner) >>> >>> -chris >> >> In theory, that’s what IRRs are for. >> >> In practice, while they offer better theoretical capabilities if stronger authentication were added, the current implementation and acceptance leaves much to be desired. > > Judging a global ecosystem just by what ARIN does is perhaps some of the issue. ARIN seems to be the outlier here as has been measured. An ARIN prefix ROA is less valuable than the other regions and this is IMO deliberate on the part of ARIN. > >> However, even in theory, RPKI offers nothing of particular benefit even in its best case of widespread implementation. > > Disagree, but that’s ok. I know at $dayJob I’m preparing the way, but it’s much harder than it should be due to the nature of our business. > > - Jared What does RPKI offer other than a way to know what to spoof in a prepend for your forged announcement? Owen From owen at delong.com Tue Sep 18 21:32:18 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Sep 2018 14:32:18 -0700 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> Message-ID: <5066C82B-6D8D-44CF-AD7B-B9AC258D41B5@delong.com> > On Sep 18, 2018, at 2:15 PM, Christopher Morrow wrote: > > > > On Tue, Sep 18, 2018 at 1:33 PM nusenu > wrote: > Christopher Morrow wrote: > > Perhaps this was answered elsewhere, but: "Why is this something > > ARIN (the org) should take on?" > > Thanks for this question, I believe this is an important one. > > I reasoned about why I think RIRs are in a good position to send these emails here: [1] > but I will quote from it for convenience: > > > Notifying affected IP Holders > > > > The natural next step (and that was our initial intention when > > looking at INVALIDs) would be to send out emails to affected IP > > holders and ask them to address the INVALIDs but although that could > > be automated, we believe the impact would be better, if that email > > came from some trusted entity like the RIR relevant to the affected > > IP holder instead of a random entity they never had any contact > > before (us). > > > > Asking RIRs to reach out to their members also scales better since > > every RIR would only have to take care of their own members. > [...] > > > i don't know that the contacts the RIR has for the entity is necessarily the one that controls/deals-with the RPKI data though. It sort of has to be, as managing your RPKI data (at least in the ARIN region) involves doing it through your ARIN On-Line account which must be associated with the ORG associated with the resources in question. > I also think that generally if folk set all that up they probably know (or will soon enough) that they have a mistake. You overestimate some things here. > Generally speaking, I think "folk should fix themselves, and maintain/monitor their configuration", that ARIN (or anyone else sending 'unsolicited email') here is going to end badly in the worst case and 'not have any effect' in the majority of cases. Agreed. > > [1] https://medium.com/@nusenu/towards-cleaning-up-rpki-invalids-d69b03ab8a8c > > > > Why can't (or why isn't) this something that 'many' > > monitoring/alerting companies/orgs are offering? > > There are companies offering BGP monitoring including RPKI ROAs, but > the affected IP holders are unlikely customers of those monitoring > services or generally aware of the problem. > > > ok, maybe they should though? :) I love a good tautology. > > > it's unclear, to me, why ARIN is in any better position than any > > other party to perform this sort of activity? I would expect that, at > > the base level, "I just got random/unexpected email from ARIN?" will > > get dropped in the spam-can, while: "My monitoring company to which I > > signed up/contracted emailed into my ticket-system for action.. > > better go do something!" is the path to incentivize. > > The problem is how do you make operators aware of the problem in the first place. > > > ideally they are aware of thier own config, have a person(s) responsible for managing that configuration and care about reachability... if they don't have that today, they will soon enough. Optimist! Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Tue Sep 18 21:32:42 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 18 Sep 2018 14:32:42 -0700 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: <94EBD5EC-F723-45BC-A6AD-10895E2B8C0E@delong.com> References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180918173542.GE58800@vurt.meerval.net> <94EBD5EC-F723-45BC-A6AD-10895E2B8C0E@delong.com> Message-ID: On Tue, Sep 18, 2018 at 12:04 PM Owen DeLong wrote: > > > On Sep 18, 2018, at 11:06 AM, Christopher Morrow > wrote: > > > > On Tue, Sep 18, 2018 at 10:36 AM Job Snijders wrote: > >> Owen, >> >> On Tue, Sep 18, 2018 at 10:23:42AM -0700, Owen DeLong wrote: >> > Personally, since all RPKI accomplishes is providing a >> > cryptographically signed notation of origin ASNs that hijackers should >> > prepend to their announcements in order to create an aura of >> > credibility, I think we should stop throwing resources down this >> > rathole. >> I think you underestimate how valuable RPKI based Origin Validation >> (even just by itself) is in today's Internet landscape. >> >> If you are aware of other efforts or more fruitful approaches please let >> us know. >> >> > Perhaps said another way: > > "How would you figure out what prefixes your bgp peer(s) should be sending > you?" > (in an automatable, and verifiable manner) > > -chris > > > In theory, that’s what IRRs are for. > > it's not worked out so far. there's no real authorization/authentication of note on the data set via the irr. you have no real way of knowing that 'as12 should be announcing 157.130.0.0/16' ... except by chasing the arin/ripe/etc records today, something that those orgs stamp and which machines could validate without people using eyeballs would sure be nice... Oh, that's what RPKI is supposed to provide. > In practice, while they offer better theoretical capabilities if stronger > authentication were added, the current implementation and acceptance leaves > much to be desired. > and has for approximately 30 yrs... I don't imagine magically it's going to get better in the next 30 either. > > However, even in theory, RPKI offers nothing of particular benefit even in > its best case of widespread implementation. > > "rir says owen can originate route FOO" "ROA for 157.130.1.0/24 says OWEN can originate" those seem like valuable pieces of information. Especially since I can know this through some machine parseable fashion. -chris > Owen > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Tue Sep 18 21:34:57 2018 From: job at ntt.net (Job Snijders) Date: Tue, 18 Sep 2018 21:34:57 +0000 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: <94EBD5EC-F723-45BC-A6AD-10895E2B8C0E@delong.com> References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180918173542.GE58800@vurt.meerval.net> <94EBD5EC-F723-45BC-A6AD-10895E2B8C0E@delong.com> Message-ID: <20180918213457.GA14661@vurt.meerval.net> On Tue, Sep 18, 2018 at 12:04:19PM -0700, Owen DeLong wrote: > > Perhaps said another way: > > > > "How would you figure out what prefixes your bgp peer(s) should be sending you?" > > (in an automatable, and verifiable manner) > > In theory, that’s what IRRs are for. You may be overlooking the fact that the semantics of an IRR route object are subtly different than those of a RPKI ROA. The Prefix-to-AS Mapping Database concept as introduced Section 2 of RFC 6811 is a huge step forward compared to the (somewhat loosely defined) semantics of IRR route objects. RPKI ROAs are more than "IRR with crypto": IRR objects are basically a list of unverifiable attestations with no proof of termination. Whereas when that same information is published through the RPKI, we now know two things: (1) the owner of the resource consented to the creation of the object and (2) any BGP UPDATE that conflicts with covering RPKI ROAs is invalid. In other words, RPKI and the Prefix-to-AS validation procedure give us much more definitive inputs for routing policies compared to what can be derived from the IRR. I simply view RPKI as a successor to the IRR system with some much needed improvements. > In practice, while they offer better theoretical capabilities if > stronger authentication were added, the current implementation and > acceptance leaves much to be desired. Luckily multiple projects are passing through the pipeline to reduce the risk some IRRs represented. https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-implementation https://teamarin.net/2018/07/12/the-path-forward/ Considering that RPKI and IRR will co-exist in one form or another for a wihle it is encouraging to see success in patching loopholes. > However, even in theory, RPKI offers nothing of particular benefit > even in its best case of widespread implementation. I can't really wrap my head around how you can arrive at such a conclusion in light of all the information that has been provided to you. So perhaps we'll have to agree to disagree. RPKI is useful in context of a defense in depth strategy. If one combines "peerlock" AS_PATH filters with origin validation the end result is bullet proof. Even if NTT is the only one to deploy this combination, the benefits are notable. Kind regards, Job From owen at delong.com Tue Sep 18 21:35:44 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Sep 2018 14:35:44 -0700 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180918173542.GE58800@vurt.meerval.net> <94EBD5EC-F723-45BC-A6AD-10895E2B8C0E@delong.com> Message-ID: > > "rir says owen can originate route FOO" > "ROA for 157.130.1.0/24 says OWEN can originate" > Nope… ROA says (e.g.) AS1734 (or anyone willing to impersonate AS1734) can originate 192.159.10.0/24. > those seem like valuable pieces of information. Especially since I can know this through some machine parseable fashion. I would agree if you had some way to distinguish AS1734 originating FOO from AS174 originating FOO with a prepend of AS1734. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Tue Sep 18 21:39:22 2018 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 18 Sep 2018 16:39:22 -0500 (CDT) Subject: Brovade/Foundry VLAN translation Message-ID: <378036276.67835.1537306762455.JavaMail.zimbra@ics-il.net> I'm not thinking so, but I figured I'd ask here. Is there any way to do VLAN translation on the Brocade VDX-6720 or the Foundry FESX424? Worst case, I'll burn a couple ports looping out and then back in. We are looking to replace the Foundrys with Arista 7050s at some point. -----Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe Brothers WISP From morrowc.lists at gmail.com Tue Sep 18 21:41:44 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 18 Sep 2018 14:41:44 -0700 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: <5066C82B-6D8D-44CF-AD7B-B9AC258D41B5@delong.com> References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <5066C82B-6D8D-44CF-AD7B-B9AC258D41B5@delong.com> Message-ID: On Tue, Sep 18, 2018 at 2:32 PM Owen DeLong wrote: > > > On Sep 18, 2018, at 2:15 PM, Christopher Morrow > wrote: > > > > On Tue, Sep 18, 2018 at 1:33 PM nusenu wrote: > >> Christopher Morrow wrote: >> > Perhaps this was answered elsewhere, but: "Why is this something >> > ARIN (the org) should take on?" >> >> Thanks for this question, I believe this is an important one. >> >> I reasoned about why I think RIRs are in a good position to send these >> emails here: [1] >> but I will quote from it for convenience: >> >> > Notifying affected IP Holders >> > >> > The natural next step (and that was our initial intention when >> > looking at INVALIDs) would be to send out emails to affected IP >> > holders and ask them to address the INVALIDs but although that could >> > be automated, we believe the impact would be better, if that email >> > came from some trusted entity like the RIR relevant to the affected >> > IP holder instead of a random entity they never had any contact >> > before (us). >> > >> > Asking RIRs to reach out to their members also scales better since >> > every RIR would only have to take care of their own members. >> [...] >> >> > i don't know that the contacts the RIR has for the entity is necessarily > the one that controls/deals-with the RPKI data though. > > > It sort of has to be, as managing your RPKI data (at least in the ARIN > region) involves doing it through your ARIN On-Line account which must be > associated with the ORG associated with the resources in question. > > I think I can manage my employer's RPKI data, and I'm not on the tech/admin/etc handles... I think I can also ask the person(s) who are to do it and they may have no idea what I'm asking beyond: "click these 5 things, type that thing, thanks!" > I also think that generally if folk set all that up they probably know > > > (or will soon enough) that they have a mistake. > > > You overestimate some things here. > > probably, but ... eventually if your internet gets very small you'll look at why. > Generally speaking, I think "folk should fix themselves, and > maintain/monitor their configuration", that ARIN (or anyone else sending > 'unsolicited email') here is going to end badly in the worst case and 'not > have any effect' in the majority of cases. > > > Agreed. > > perhaps this is really my point: "I have no confidence that ARIN doing this (or anyone else except an upstream network/peer) is going to effect change" > > >> [1] >> https://medium.com/@nusenu/towards-cleaning-up-rpki-invalids-d69b03ab8a8c >> >> >> > Why can't (or why isn't) this something that 'many' >> > monitoring/alerting companies/orgs are offering? >> >> There are companies offering BGP monitoring including RPKI ROAs, but >> the affected IP holders are unlikely customers of those monitoring >> services or generally aware of the problem. >> >> > ok, maybe they should though? :) > > > I love a good tautology. > > I'm glad you enjoyed it... you found the easter-egg! Generally speaking though (and trying to be constructive) people who use BGP to manage reachability to their network resources really should monitor what their resources look like externally... and folk do offer services which do these things. "As seen on TV .... bgp monitoring for you!" :) > > >> > it's unclear, to me, why ARIN is in any better position than any >> > other party to perform this sort of activity? I would expect that, at >> > the base level, "I just got random/unexpected email from ARIN?" will >> > get dropped in the spam-can, while: "My monitoring company to which I >> > signed up/contracted emailed into my ticket-system for action.. >> > better go do something!" is the path to incentivize. >> >> The problem is how do you make operators aware of the problem in the >> first place. >> >> > ideally they are aware of thier own config, have a person(s) responsible > for managing that configuration and care about reachability... if they > don't have that today, they will soon enough. > > > Optimist! > > yea... it's probably as optimistic as your hope that irr data will get better? :) I think as more things depend on reachability the state will improve... or that's my hope, yes. > Owen > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Sep 18 21:44:30 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Sep 2018 14:44:30 -0700 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: <20180918213457.GA14661@vurt.meerval.net> References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180918173542.GE58800@vurt.meerval.net> <94EBD5EC-F723-45BC-A6AD-10895E2B8C0E@delong.com> <20180918213457.GA14661@vurt.meerval.net> Message-ID: <4145438B-D18D-44ED-BF7E-575F137E7817@delong.com> > On Sep 18, 2018, at 2:34 PM, Job Snijders wrote: > > On Tue, Sep 18, 2018 at 12:04:19PM -0700, Owen DeLong wrote: >>> Perhaps said another way: >>> >>> "How would you figure out what prefixes your bgp peer(s) should be sending you?" >>> (in an automatable, and verifiable manner) >> >> In theory, that’s what IRRs are for. > > You may be overlooking the fact that the semantics of an IRR route > object are subtly different than those of a RPKI ROA. The Prefix-to-AS > Mapping Database concept as introduced Section 2 of RFC 6811 is a huge > step forward compared to the (somewhat loosely defined) semantics of IRR > route objects. > > RPKI ROAs are more than "IRR with crypto": IRR objects are basically a > list of unverifiable attestations with no proof of termination. Whereas Right… Hence my call for IRRs with stronger authentication and validation. (i.e. IRRs run by RIRs that have the same level of maintenance authentication and authorization requirements as current RPKI implementations). > when that same information is published through the RPKI, we now know > two things: (1) the owner of the resource consented to the creation of > the object and (2) any BGP UPDATE that conflicts with covering RPKI ROAs > is invalid. Yes, but, what you don’t know is whether any BGP UPDATE that contains the valid origin ASN as origin came from the origin ASN it claims. Instead, you provided a cryptographically signed recipe for believable spoofing. Actually, they’re quite a bit less… They provide no path data. ROAs are useful for one hop level validation. At the second AS hop they are 100% useless. > In other words, RPKI and the Prefix-to-AS validation procedure give us > much more definitive inputs for routing policies compared to what can be > derived from the IRR. Please explain to me how you distinguish good from bad in the following scenario… You peer with AS6939. You receive routes for 2001:db8:f300::/48 with the following AS Paths 1. 6939 1239 54049 2312 1734 2. 6939 44046 12049 174 1734 Which one is valid? Which one is not? How did the ROA tell you this? With the IRR, I can (theoretically) compare an AS Path to the valid set of path associations documented in RPSL. (modulo lack of participation/implementation, which RPKI likewise suffers from). With RPKI, I can’t tell anything. > I simply view RPKI as a successor to the IRR system with some much > needed improvements. Your view is, IMHO, very distorted. >> In practice, while they offer better theoretical capabilities if >> stronger authentication were added, the current implementation and >> acceptance leaves much to be desired. > > Luckily multiple projects are passing through the pipeline to reduce the > risk some IRRs represented. > > https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-implementation > https://teamarin.net/2018/07/12/the-path-forward/ > > Considering that RPKI and IRR will co-exist in one form or another for a > wihle it is encouraging to see success in patching loopholes. Yep… Properly implemented and adopted, IRRs show some progress for actual path validation abilities, including origin. >> However, even in theory, RPKI offers nothing of particular benefit >> even in its best case of widespread implementation. > > I can't really wrap my head around how you can arrive at such a > conclusion in light of all the information that has been provided to > you. So perhaps we'll have to agree to disagree. See above. What is it you believe RPKI offers beyond 1 hop that is anything more than a cryptographically signed recipe for believable spoofing? > RPKI is useful in context of a defense in depth strategy. If one > combines "peerlock" AS_PATH filters with origin validation the end > result is bullet proof. Even if NTT is the only one to deploy this > combination, the benefits are notable. Indeed, if peerlock gets wider deployment, it might prove useful. But unless I’m really misunderstanding peerlock, I don’t see that RPKI brings much else to the table in addition. Owen From job at ntt.net Tue Sep 18 21:58:20 2018 From: job at ntt.net (Job Snijders) Date: Tue, 18 Sep 2018 21:58:20 +0000 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: References: <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180918173542.GE58800@vurt.meerval.net> <94EBD5EC-F723-45BC-A6AD-10895E2B8C0E@delong.com> Message-ID: <20180918215820.GB14661@vurt.meerval.net> On Tue, Sep 18, 2018 at 02:35:44PM -0700, Owen DeLong wrote: > > "rir says owen can originate route FOO" > > "ROA for 157.130.1.0/24 says OWEN can originate" > > Nope… ROA says (e.g.) AS1734 (or anyone willing to impersonate AS1734) > can originate 192.159.10.0/24. I'd phrase slightly different (assuming there is only one ROA): the ROA says ONLY AS1734 (or anyone willing to impersonate AS1734) can originate 192.159.10.0/24. With IRR, the crucial addition of the word "ONLY" in the above sentence is not possible. > > those seem like valuable pieces of information. Especially since I > > can know this through some machine parseable fashion. > > I would agree if you had some way to distinguish AS1734 originating > FOO from AS174 originating FOO with a prepend of AS1734. In the common scenario you can distinguish those with today's technology. As mentioned before - dense peering (having the shortest AS_PATH) or the peerlock approach for all *practical* intents solve the issue of path validation. You can try spoofing AS 7018 - you'll notice that your announcements won't make it into NTT. Having just that validated path (which is only one hop) is a very strong defense mechanism. Let's take another example: Google offers access to one of the world's largest DNS resolver services, Cloudflare hosts lots of authoritative DNS. According to PeeringDB they have quite some locations in common with each other so let's assume they directly peer with each other. If both sides create ROAs for their prefixes, and ROAs for the prefixes that host the auth side, and both sides perform RPKI Origin Validation; an attacker cannot inject itself between the two. One can argue "this only helped google and cloudflare" - but on the other hand anno 2018 the Internet experience for the average end user is composed from services hosted by a relatively small number of providers. Preventing disruptions of communication between just those few players has significant implications for all of us. Kind regards, Job From nusenu-lists at riseup.net Tue Sep 18 22:04:00 2018 From: nusenu-lists at riseup.net (nusenu) Date: Tue, 18 Sep 2018 22:04:00 +0000 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> Message-ID: <668cb765-1a13-1243-b8e7-3993a4f046ce@riseup.net> Christopher Morrow: >> Yes that is what I had in mind (notification via email to the tech >> contact). >> >> > i'm positive that will end in sadness. we can also send snail mail :) after all ~80 or so entities is a manageable amount of organizations to notify in the ARIN region. -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From job at ntt.net Tue Sep 18 22:07:56 2018 From: job at ntt.net (Job Snijders) Date: Tue, 18 Sep 2018 22:07:56 +0000 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: <4145438B-D18D-44ED-BF7E-575F137E7817@delong.com> References: <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180918173542.GE58800@vurt.meerval.net> <94EBD5EC-F723-45BC-A6AD-10895E2B8C0E@delong.com> <20180918213457.GA14661@vurt.meerval.net> <4145438B-D18D-44ED-BF7E-575F137E7817@delong.com> Message-ID: <20180918220756.GC14661@vurt.meerval.net> On Tue, Sep 18, 2018 at 02:44:30PM -0700, Owen DeLong wrote: > ROAs are useful for one hop level validation. At the second AS hop > they are 100% useless. This conversation cannot be had without acknowledging there are multiple layers of defense in securing BGP. We should also acknowledge that the majority of Internet traffic passes over AS_PATHs that are only one hop. Networks that exchange significant amounts of traffic, tend to peer directly with each other. > > In other words, RPKI and the Prefix-to-AS validation procedure give > > us much more definitive inputs for routing policies compared to what > > can be derived from the IRR. > > Please explain to me how you distinguish good from bad in the > following scenario… You peer with AS6939. You receive routes for > 2001:db8:f300::/48 with the following AS Paths > > 1. 6939 1239 54049 2312 1734 > 2. 6939 44046 12049 174 1734 > > Which one is valid? Which one is not? How did the ROA tell you this? Both path 1 and 2 are invalid, because of peerlock we'd never accept 1239 behind 6939, or 174 behind 6939. AS_PATH filtering combined with Origin Validation is where the magic is. > > RPKI is useful in context of a defense in depth strategy. If one > > combines "peerlock" AS_PATH filters with origin validation the end > > result is bullet proof. Even if NTT is the only one to deploy this > > combination, the benefits are notable. > > Indeed, if peerlock gets wider deployment, it might prove useful. But > unless I’m really misunderstanding peerlock, I don’t see that RPKI > brings much else to the table in addition. Wide deployment is not relevant, this is a unilateral defense mechanism, so I fear there may indeed be a degree of misunderstanding. Kind regards, Job From tanaka at netcombb.co.jp Tue Sep 18 15:52:25 2018 From: tanaka at netcombb.co.jp (Jun Tanaka) Date: Wed, 19 Sep 2018 00:52:25 +0900 Subject: Console Servers In-Reply-To: References: Message-ID: <3C05F647-002D-4392-B1B1-06D85FCE34DC@netcombb.co.jp> How about SMART CS series by Seiko solutions? https://www.seiko-sol.co.jp/en/products/console-server/ -- Jun Tanaka - NetComBB/S.N.I -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at luftivennad.com Tue Sep 18 16:51:53 2018 From: nanog at luftivennad.com (A.T) Date: Tue, 18 Sep 2018 19:51:53 +0300 Subject: Piter-IX and GOOGLE (AS15169) Message-ID: Hello, I see AS15169 announcements from Piter-IX (https://www.peeringdb.com/ix/2149), but Google PeeringDB entry don't seem include Piter-IX. Any idea, is PeeringDB out of date here or should I be worried? Best regards A.T From nusenu-lists at riseup.net Tue Sep 18 23:53:00 2018 From: nusenu-lists at riseup.net (nusenu) Date: Tue, 18 Sep 2018 23:53:00 +0000 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: <668cb765-1a13-1243-b8e7-3993a4f046ce@riseup.net> References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <668cb765-1a13-1243-b8e7-3993a4f046ce@riseup.net> Message-ID: > Christopher Morrow wrote: >>> Yes that is what I had in mind (notification via email to the tech >>> contact). >>> >>> >> i'm positive that will end in sadness. > > we can also send snail mail :) > after all ~80 or so entities is a manageable amount of organizations to > notify in the ARIN region. correction: in the ARIN region there are just about 30 organizations to contact (~80 was for APNIC) -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From morrowc.lists at gmail.com Wed Sep 19 00:03:53 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 18 Sep 2018 17:03:53 -0700 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <668cb765-1a13-1243-b8e7-3993a4f046ce@riseup.net> Message-ID: On Tue, Sep 18, 2018 at 4:54 PM nusenu wrote: > > Christopher Morrow wrote: > >>> Yes that is what I had in mind (notification via email to the tech > >>> contact). > >>> > >>> > >> i'm positive that will end in sadness. > > > > we can also send snail mail :) > > after all ~80 or so entities is a manageable amount of organizations to > > notify in the ARIN region. > > correction: in the ARIN region there are just about 30 organizations to > contact > (~80 was for APNIC) > > cool, sounds like you are all done in just ~20 USD of stamps. -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Wed Sep 19 00:16:38 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 18 Sep 2018 17:16:38 -0700 Subject: Piter-IX and GOOGLE (AS15169) In-Reply-To: References: Message-ID: On Tue, Sep 18, 2018 at 3:34 PM A.T wrote: > Hello, > > I see AS15169 announcements from Piter-IX > (https://www.peeringdb.com/ix/2149), but Google PeeringDB entry don't seem > include Piter-IX. > Any idea, is PeeringDB out of date here or should I be worried? > > send me an as-path you see please? > Best regards > A.T > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Wed Sep 19 00:18:51 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 18 Sep 2018 17:18:51 -0700 Subject: Piter-IX and GOOGLE (AS15169) In-Reply-To: References: Message-ID: On Tue, Sep 18, 2018 at 3:34 PM A.T wrote: > Hello, > > I see AS15169 announcements from Piter-IX > (https://www.peeringdb.com/ix/2149), but Google PeeringDB entry don't seem > include Piter-IX. > Any idea, is PeeringDB out of date here or should I be worried? > > sorry, looks like peeringdb needs an update, I will ask the 15169 folk to update. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed Sep 19 01:18:00 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Sep 2018 18:18:00 -0700 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: <20180918215820.GB14661@vurt.meerval.net> References: <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180918173542.GE58800@vurt.meerval.net> <94EBD5EC-F723-45BC-A6AD-10895E2B8C0E@delong.com> <20180918215820.GB14661@vurt.meerval.net> Message-ID: > On Sep 18, 2018, at 14:58 , Job Snijders wrote: > > On Tue, Sep 18, 2018 at 02:35:44PM -0700, Owen DeLong wrote: >>> "rir says owen can originate route FOO" >>> "ROA for 157.130.1.0/24 says OWEN can originate" >> >> Nope… ROA says (e.g.) AS1734 (or anyone willing to impersonate AS1734) >> can originate 192.159.10.0/24. > > I'd phrase slightly different (assuming there is only one ROA): the ROA > says ONLY AS1734 (or anyone willing to impersonate AS1734) can originate > 192.159.10.0/24. > > With IRR, the crucial addition of the word "ONLY" in the above sentence > is not possible. That depends. If you ONLY allow the maintainer of NET-192.159.10.0/24 to update the route objects for it, then the word ONLY is effectively present by the lack of any other route objects. > >>> those seem like valuable pieces of information. Especially since I >>> can know this through some machine parseable fashion. >> >> I would agree if you had some way to distinguish AS1734 originating >> FOO from AS174 originating FOO with a prepend of AS1734. > > In the common scenario you can distinguish those with today's > technology. As mentioned before - dense peering (having the shortest > AS_PATH) or the peerlock approach for all *practical* intents solve the > issue of path validation. You can try spoofing AS 7018 - you'll notice > that your announcements won't make it into NTT. Having just that > validated path (which is only one hop) is a very strong defense > mechanism. You chopped out my example, which had equal AS Path lengths. Sure, I might not be able to announce something to you for an AS that you’re directly peered with, but I can still spoof pretty much anything that’s more than one hop away as long as I can get one of your peers to pass it along. > Let's take another example: Google offers access to one of the world's > largest DNS resolver services, Cloudflare hosts lots of authoritative > DNS. According to PeeringDB they have quite some locations in common > with each other so let's assume they directly peer with each other. If > both sides create ROAs for their prefixes, and ROAs for the prefixes > that host the auth side, and both sides perform RPKI Origin Validation; > an attacker cannot inject itself between the two. Again, you’re reducing the problem set to single hop which I admit RPKI solves (though I’d argue that if someone has access to insert themselves between the two physically, RPKI does little to help) > One can argue "this only helped google and cloudflare" - but on the > other hand anno 2018 the Internet experience for the average end user is > composed from services hosted by a relatively small number of providers. > Preventing disruptions of communication between just those few players > has significant implications for all of us. So RPKI is great if we can just reduce the internet diameter to 1, in which case MD5 passwords on your BGP sessions pretty much accomplishes the same thing with a lot less kerfuffle. Owen From owen at delong.com Wed Sep 19 01:21:56 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Sep 2018 18:21:56 -0700 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: <20180918220756.GC14661@vurt.meerval.net> References: <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180918173542.GE58800@vurt.meerval.net> <94EBD5EC-F723-45BC-A6AD-10895E2B8C0E@delong.com> <20180918213457.GA14661@vurt.meerval.net> <4145438B-D18D-44ED-BF7E-575F137E7817@delong.com> <20180918220756.GC14661@vurt.meerval.net> Message-ID: <4BDDAFA6-55E3-4FF2-BB74-2D25973E95A3@delong.com> > On Sep 18, 2018, at 15:07 , Job Snijders wrote: > > On Tue, Sep 18, 2018 at 02:44:30PM -0700, Owen DeLong wrote: >> ROAs are useful for one hop level validation. At the second AS hop >> they are 100% useless. > > This conversation cannot be had without acknowledging there are multiple > layers of defense in securing BGP. We should also acknowledge that the > majority of Internet traffic passes over AS_PATHs that are only one hop. > Networks that exchange significant amounts of traffic, tend to peer > directly with each other. Actually, I don’t buy that at all. Without going into too much detail, I know of at least one former employer who is quite well peered, distributes a great deal of traffic and sends a tremendous amount of it via multiple ASNs. > >>> In other words, RPKI and the Prefix-to-AS validation procedure give >>> us much more definitive inputs for routing policies compared to what >>> can be derived from the IRR. >> >> Please explain to me how you distinguish good from bad in the >> following scenario… You peer with AS6939. You receive routes for >> 2001:db8:f300::/48 with the following AS Paths >> >> 1. 6939 1239 54049 2312 1734 >> 2. 6939 44046 12049 174 1734 >> >> Which one is valid? Which one is not? How did the ROA tell you this? > > Both path 1 and 2 are invalid, because of peerlock we'd never accept > 1239 behind 6939, or 174 behind 6939. AS_PATH filtering combined with > Origin Validation is where the magic is. OK, poor examples crafted at random. Point is there are plenty of valid AS Paths out there that you can’t actually validate. >>> RPKI is useful in context of a defense in depth strategy. If one >>> combines "peerlock" AS_PATH filters with origin validation the end >>> result is bullet proof. Even if NTT is the only one to deploy this >>> combination, the benefits are notable. >> >> Indeed, if peerlock gets wider deployment, it might prove useful. But >> unless I’m really misunderstanding peerlock, I don’t see that RPKI >> brings much else to the table in addition. > > Wide deployment is not relevant, this is a unilateral defense mechanism, > so I fear there may indeed be a degree of misunderstanding. Point being that there are very very few ASNs using peer lock. Peer lock alone AIUI pretty well covers the issue. RPKI provides very little (if any) verification. Owen From ESundberg at nitelusa.com Wed Sep 19 02:27:49 2018 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Wed, 19 Sep 2018 02:27:49 +0000 Subject: Console Servers In-Reply-To: <3C05F647-002D-4392-B1B1-06D85FCE34DC@netcombb.co.jp> References: <3C05F647-002D-4392-B1B1-06D85FCE34DC@netcombb.co.jp> Message-ID: Perle IOLAN SCS series is great. We have them all over the United States. From: NANOG On Behalf Of Jun Tanaka Sent: Tuesday, September 18, 2018 10:52 AM To: nanog at nanog.org; Alan Hannan ; NANOG Subject: Re: Console Servers How about SMART CS series by Seiko solutions? https://www.seiko-sol.co.jp/en/products/console-server/ -- Jun Tanaka - NetComBB/S.N.I ________________________________ 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 morrowc.lists at gmail.com Wed Sep 19 04:29:02 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 18 Sep 2018 21:29:02 -0700 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: <4BDDAFA6-55E3-4FF2-BB74-2D25973E95A3@delong.com> References: <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180918173542.GE58800@vurt.meerval.net> <94EBD5EC-F723-45BC-A6AD-10895E2B8C0E@delong.com> <20180918213457.GA14661@vurt.meerval.net> <4145438B-D18D-44ED-BF7E-575F137E7817@delong.com> <20180918220756.GC14661@vurt.meerval.net> <4BDDAFA6-55E3-4FF2-BB74-2D25973E95A3@delong.com> Message-ID: On Tue, Sep 18, 2018 at 6:22 PM Owen DeLong wrote: > > > > On Sep 18, 2018, at 15:07 , Job Snijders wrote: > > > > On Tue, Sep 18, 2018 at 02:44:30PM -0700, Owen DeLong wrote: > >> ROAs are useful for one hop level validation. At the second AS hop > >> they are 100% useless. > > > > This conversation cannot be had without acknowledging there are multiple > > layers of defense in securing BGP. We should also acknowledge that the > > majority of Internet traffic passes over AS_PATHs that are only one hop. > > Networks that exchange significant amounts of traffic, tend to peer > > directly with each other. > > Actually, I don’t buy that at all. > > Without going into too much detail, I know of at least one former employer > who is quite > well peered, distributes a great deal of traffic and sends a tremendous > amount of it > via multiple ASNs. > > an IP resource holder can sign multiple ROA for a single prefix, it's perfectly valid to have: 157.130.0.0/16 AS112 157.130.0.0/16 AS113 157.130.0.0/16 AS701 So 'peered well via multiple ASN isn't really a problem here'. Are you making an argument of the form: "1% of the problems are not solved so this solution can't possibly work" ? Using ROA from the RPKI system tied through/to the IRR data and applied as filters on the bgp sessions of a network should provide that ASN with more assurance that they will not accept and propagate a route hijack or mistake. Adding in validation is nice as well, and may allow you to be a little less diligent about route filtering... I think more than 1 protection is a good plan though (OV + filters seems sane to me, especially in a world where you can automate that whole lot) > > >>> In other words, RPKI and the Prefix-to-AS validation procedure give > >>> us much more definitive inputs for routing policies compared to what > >>> can be derived from the IRR. > >> > >> Please explain to me how you distinguish good from bad in the > >> following scenario… You peer with AS6939. You receive routes for > >> 2001:db8:f300::/48 with the following AS Paths > >> > >> 1. 6939 1239 54049 2312 1734 > >> 2. 6939 44046 12049 174 1734 > >> > >> Which one is valid? Which one is not? How did the ROA tell you this? > > > > Both path 1 and 2 are invalid, because of peerlock we'd never accept > > 1239 behind 6939, or 174 behind 6939. AS_PATH filtering combined with > > Origin Validation is where the magic is. > > OK, poor examples crafted at random. Point is there are plenty of valid AS > Paths > out there that you can’t actually validate. > I think Job's point is that there really are note that many... perhaps that's an NTT particular view? I know that my production network's view is similar in 'shorter as paths'. I expect that in large-isp-land it's more prevalent than not. > >>> RPKI is useful in context of a defense in depth strategy. If one > >>> combines "peerlock" AS_PATH filters with origin validation the end > >>> result is bullet proof. Even if NTT is the only one to deploy this > >>> combination, the benefits are notable. > >> > >> Indeed, if peerlock gets wider deployment, it might prove useful. But > >> unless I’m really misunderstanding peerlock, I don’t see that RPKI > >> brings much else to the table in addition. > > > > Wide deployment is not relevant, this is a unilateral defense mechanism, > > so I fear there may indeed be a degree of misunderstanding. > > Point being that there are very very few ASNs using peer lock. Peer lock > alone AIUI pretty well covers the issue. RPKI provides very little (if any) > verification. > > I suppose if you are happy just doing peer lock on/for your network and customers then cool! The RPKI system isn't being forced on you. It seems like a helpful addition to me, but that may not be your outlook. -chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at luftivennad.com Wed Sep 19 06:31:24 2018 From: nanog at luftivennad.com (A.T) Date: Wed, 19 Sep 2018 09:31:24 +0300 Subject: Piter-IX and GOOGLE (AS15169) In-Reply-To: References: Message-ID: <846d1d95c19dd097daecfe8da40ab06a.squirrel@foto.luftivennad.com> Hello! Thanks for reply! Announcement from route server contains only 15169 in as-path. Best regards, A.T > On Tue, Sep 18, 2018 at 3:34 PM A.T wrote: > >> Hello, >> >> I see AS15169 announcements from Piter-IX >> (https://www.peeringdb.com/ix/2149), but Google PeeringDB entry don't >> seem >> include Piter-IX. >> Any idea, is PeeringDB out of date here or should I be worried? >> >> > send me an as-path you see please? > > > >> Best regards >> A.T >> >> >> >> >> >> >> > From morrowc.lists at gmail.com Wed Sep 19 06:45:58 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 18 Sep 2018 23:45:58 -0700 Subject: Piter-IX and GOOGLE (AS15169) In-Reply-To: <846d1d95c19dd097daecfe8da40ab06a.squirrel@foto.luftivennad.com> References: <846d1d95c19dd097daecfe8da40ab06a.squirrel@foto.luftivennad.com> Message-ID: On Tue, Sep 18, 2018 at 11:31 PM A.T wrote: > Hello! > > Thanks for reply! > Announcement from route server contains only 15169 in as-path. > > ok, cool... Ideally the folk with peering-db access are already along fixing the records :) (it's totally possible they are still sleeping... but they've got a request in their inbox to assist) thanks for pointing out the data problem AND for asking if the peering was real :) -chris > Best regards, > A.T > > > On Tue, Sep 18, 2018 at 3:34 PM A.T wrote: > > > >> Hello, > >> > >> I see AS15169 announcements from Piter-IX > >> (https://www.peeringdb.com/ix/2149), but Google PeeringDB entry don't > >> seem > >> include Piter-IX. > >> Any idea, is PeeringDB out of date here or should I be worried? > >> > >> > > send me an as-path you see please? > > > > > > > >> Best regards > >> A.T > >> > >> > >> > >> > >> > >> > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Wed Sep 19 07:44:57 2018 From: job at ntt.net (Job Snijders) Date: Wed, 19 Sep 2018 07:44:57 +0000 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: References: <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180918173542.GE58800@vurt.meerval.net> <94EBD5EC-F723-45BC-A6AD-10895E2B8C0E@delong.com> <20180918215820.GB14661@vurt.meerval.net> Message-ID: <20180919074457.GD14661@vurt.meerval.net> On Tue, Sep 18, 2018 at 06:18:00PM -0700, Owen DeLong wrote: > That depends. If you ONLY allow the maintainer of NET-192.159.10.0/24 > to update the route objects for it, then the word ONLY is effectively > present by the lack of any other route objects. Ah, so you are now applying the RPKI Origin Validation procedure to a non-existent flavor of IRR? :-) Today I can create route-objects covering 192.159.10.0/24 in a number of IRR databases and there is nothing you can do to prevent that, this simply is not the case with RPKI. I prefer an existing system (RPKI) over hypotheticals (Owen's IRR). Secondly, I've also noticed you only emphasize an adversarial angle (origin spoofing), but there are other angles too. The majority of today's BGP problems are attributable to operator mistakes (misconfigurations). Analysis has shown that most BGP incidents happen on weekdays rather than in the weekend. The number keys on our keyboards are quite close to each other and Origin Validation is very effective against typos. Another angle is bugs in BGP implementations: your neighbors doing origin validation reduces the impact and propagation of incorrect announcements from your network should you run into a software defect. > So RPKI is great if we can just reduce the internet diameter to 1 Agreed, in other words: RPKI is offers tangible benefits to those that peer directly with each other, or use peerlock. > in which case MD5 passwords on your BGP sessions pretty much > accomplishes the same thing with a lot less kerfuffle. Uhh... you may want to refresh your memory on what BGP is and how TCP-MD5 works. Kind regards, Job From morrowc.lists at gmail.com Wed Sep 19 07:44:58 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 19 Sep 2018 00:44:58 -0700 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: <0D56BF2A-A5F2-4FC5-9E66-F8733AA2BADF@delong.com> References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> <8A48B84A-7284-43D4-826D-108F9E1EF71C@6by7.net> <3d5f160c-c06c-6b13-0588-e1ee2ddacb30@efes.iucc.ac.il> <08651119-3714-4A53-ADF0-989869253BE9@delong.com> <0D56BF2A-A5F2-4FC5-9E66-F8733AA2BADF@delong.com> Message-ID: On Tue, Sep 18, 2018 at 12:28 PM Owen DeLong wrote: > > I’d argue that the difference between reasonable (≤$500 one-time and ≤$50 > MRC) and $300 MRC is within range of argument, but I cannot see any way in > which an argument can be made that $5840 MRC is not a distortion in that > same circumstance. > > captive audiences (or those which view themselves as captive) are so much fun... :( I imagine that 'away from Telaviv' in the 20ms arena is .... actually pretty hard to find, right? If you wanted to offer 'local' content locally (and offer it quickly/fastly (ha!)) it's probably pretty hard in that part of the world, right? Whether it actually 'costs' that much to pull a x-connect and maintain that x-connect is probably not as important as 'gosh it's really hard to be 'close' to ' right? which is what they are capitalizing on here. Hank, how far away is the next closest large network metro ? Riyad? Rome? Sofia?... I mean, it's all 'far' from 'isreal' (or really any part of the world) to the next decent network POP :( -------------- next part -------------- An HTML attachment was scrubbed... URL: From nusenu-lists at riseup.net Wed Sep 19 07:46:00 2018 From: nusenu-lists at riseup.net (nusenu) Date: Wed, 19 Sep 2018 07:46:00 +0000 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> Message-ID: Owen DeLong: > Personally, since all RPKI accomplishes is providing a > cryptographically signed notation of origin ASNs that hijackers > should prepend to their announcements in order to create an aura of > credibility, I think we should stop throwing resources down this > rathole. regardless of how one might think about RPKI, there are ROAs out there that reduce the visibility/reachability of certain prefixes and the general assumption is that announced prefixes would like to be reachable even if the operator doesn't care about RPKI and ROAs from the past anymore, he most likely cares about reachability from a pure operational point of view. my email was not about: "How much does one like RPKI?" it is about whether it is acceptable that RIRs (and more specifically ARIN in this mailing list's context) notify affected parties of their prefixes that suffer from stale ROAs. Even if one dislikes RPKI entirely the opinion could still be "yes notifying those parties makes sense to restore reachability". -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From morrowc.lists at gmail.com Wed Sep 19 07:47:37 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 19 Sep 2018 00:47:37 -0700 Subject: netflix OCA in a CG-NAT world In-Reply-To: <1537258832.1038722.1511816800.3B49BDE6@webmail.messagingengine.com> References: <8862102D-0FD5-47B9-A05A-0BAC3317D733@puck.nether.net> <1537258832.1038722.1511816800.3B49BDE6@webmail.messagingengine.com> Message-ID: On Tue, Sep 18, 2018 at 1:21 AM Radu-Adrian Feurdean < nanog at radu-adrian.feurdean.net> wrote: > On Mon, Sep 17, 2018, at 17:48, Jared Mauch wrote: > > > I also strongly suggest you look at how to get native IPv6 from your > > clients behind the CG-NAT rolled out. I know many folks have had issues > > Getting IPv6 to your customers is good, but they still have to use it. > > If I look at my stats, I can see that the IPv4:IPv6 ratio for Netflix is > 5.5:1, while for Google it's 1.1:1 and for Facebook 1.33:1 (peak-time ratios, when traffic is mostly from residential users) . The > best explanation I could get is people may use Netflix from devices that do > not support IPv6, such as some/most (not-so-old) Smart TVs. There's also > the issue of some brain-dead wifi APs that filter or severely limit traffic > required for proper IPv6 operation (multicast comes to my mind). > > so, first: "Thanks for getting v6 to your customers!!" because srsly, some folks (verizon residential dsl/fios) can't seem to make that happen, there's some form of serious magic obviously involved... That said, it's funny that tv's (bluray/etc) are not v6 capable?? ugh :( -chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Wed Sep 19 07:55:33 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 19 Sep 2018 00:55:33 -0700 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: <20180919074457.GD14661@vurt.meerval.net> References: <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180918173542.GE58800@vurt.meerval.net> <94EBD5EC-F723-45BC-A6AD-10895E2B8C0E@delong.com> <20180918215820.GB14661@vurt.meerval.net> <20180919074457.GD14661@vurt.meerval.net> Message-ID: > > in which case MD5 passwords on your BGP sessions pretty much > > accomplishes the same thing with a lot less kerfuffle. > > > oh gosh, sorry I missed this in the previous conversation... for folk following along at home: TCP-MD5 is really REALLY just: "better CRC(checksum)" on your BGP session, and is in no way related to which routes your bgp-peer should/could/will be sending you over that peering. Please do not confuse/conflate BGP / TCP-MD5 with routing-security :( Steve Bellovin would be shocked and appalled at such conflation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Wed Sep 19 08:07:42 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 19 Sep 2018 01:07:42 -0700 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> Message-ID: On Wed, Sep 19, 2018 at 12:51 AM nusenu wrote: > Owen DeLong: > > Personally, since all RPKI accomplishes is providing a > > cryptographically signed notation of origin ASNs that hijackers > > should prepend to their announcements in order to create an aura of > > credibility, I think we should stop throwing resources down this > > rathole. > > regardless of how one might think about RPKI, there are ROAs out > there that reduce the visibility/reachability of certain prefixes and the > general assumption is that announced prefixes would like to be reachable > even if the operator doesn't care about RPKI and ROAs from the past > anymore, he most likely cares > about reachability from a pure operational point of view. > > So, a lot like dnssec ... if you enable the RPKI functions (publish roas) I think it's very much a responsibility of the publisher to provide the correct information in an on-going and stable manner. This seems bad, at first blush, but you will not always be here to offer these recalcitrant folk a pointer to how to fix themselves, and TODAY there's: "little" penalty when it comes to getting this RPKI thing wrongly... So, ideally the folk who are 'doin it wrong' can learn, get operational proceses/procedures/personnel in place and take action for the long term... right? :) > my email was not about: "How much does one like RPKI?" > sorry, 'most' emails that mention RPKI are: "how much do you like the flavor of rpki?" :) > it is about whether it is acceptable that RIRs (and more specifically ARIN > in this mailing list's context) > notify affected parties of their prefixes that suffer from stale ROAs. > This I still think is a bad plan.. mostly because I don't think it'll help :( I think what helps is: "Oh, I cant get to and and " .... I think folk that CARE will do the right thing, folk that 'think they care' won't and will soon get disconnected from the tubez. I apologize a tad if my view that: "breaking people will force them to fix themselves" is .... rough :( Even if one dislikes RPKI entirely the opinion could still be "yes > notifying those parties makes sense > to restore reachability". > > > -- > https://twitter.com/nusenu_ > https://mastodon.social/@nusenu > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at instituut.net Wed Sep 19 08:19:37 2018 From: job at instituut.net (Job Snijders) Date: Wed, 19 Sep 2018 08:19:37 +0000 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> Message-ID: <20180919081937.GF14661@vurt.meerval.net> On Wed, Sep 19, 2018 at 01:07:42AM -0700, Christopher Morrow wrote: > > it is about whether it is acceptable that RIRs (and more > > specifically ARIN in this mailing list's context) notify affected > > parties of their prefixes that suffer from stale ROAs. > > This I still think is a bad plan.. mostly because I don't think it'll > help :( I think what helps is: "Oh, I cant get to and and > " .... I think folk that CARE will do the right > thing, folk that 'think they care' won't and will soon get > disconnected from the tubez. > > I apologize a tad if my view that: "breaking people will force them to > fix themselves" is .... rough :( What about an one-off outreach effort? We need to somehow kickstart the feedback loop, especially if we expect effects to become forceful. I'm hoping that if the invalid count is low enough it'll become more attractive for more people flip the switch and deploy OV. Kind regards, Job From jwbensley at gmail.com Wed Sep 19 08:27:33 2018 From: jwbensley at gmail.com (James Bensley) Date: Wed, 19 Sep 2018 09:27:33 +0100 Subject: Console Servers In-Reply-To: References: Message-ID: On Tue, 18 Sep 2018 at 15:26, Saku Ytti wrote: > > On Tue, 18 Sep 2018 at 16:39, Alan Hannan wrote: > > > Long ago I used Cisco 2511/2611 and was fairly happy. A little later I used portmaster and was less so. Recently I've been using Opengear and they work fairly well but the price is fairly high. I use the CM7100 and IM7100. > > Out of curiosity, how do you connect them? I see quotes around > 200USD/MRC for ethernet in US, implying 12kUSD 5 year cost on just > connectivity, add rack rental, and power and Opengear price is maybe > 10% of TCO? > > Personally I still prefer Cisco, as not to have new operating system > to automate. Add conserver to connect persistently to each console > port, so that you get persistent logs from console to your NMS, and so > that you can multiplex your console sessions. > It's hard to recover the CAPEX benefit if you need OOB platform > specific OPEX costs. For cheap OOB connectivity that scales, I've had some success with VDSL for OOB console server connections. Note that I didn't say "great"... In some DCs I've done mutual OOB swaps with other telcos in the same suite, this is usually cheap or free (excluding the one time xconnect cost, in suite xconnects often have no recurring charge) but you need to track them all, often every swap is bespoke, providers come and go so you need to replace them, if it's free you sometimes don't get maintenance alerts ;) Sometimes the DC provider has an OOB connectivity service that uses separate transit providers than we use and this often cheap too. Again this is often bespoke per DC/colo provider though. The most scalable solution I've been involved in so far is VDSL. Here in the UK lots of DCs are on-net for the national incumbent VDSL provider (BT). It means we can have the same style of connection to most DCs, same physical presentation, same cost, it eases the contract management for renewing them as we have one supplier etc. The biggest problem I've experienced with this approach is getting the copper line to the rack, some DCs charge a small fortune as copper pairs to a rack is a bespoke service for them, some do it regularly. I've just moved on from an LLU provider in the UK, a CLEC in US terminology, we had about 1200 PoPs around the UK most of which were telephone exchanges. If you want OOB in a DC it's different to a telephone exchange (well it is here), seeing as the OP hasn't mentioned if OOB will be in DCs/telephone exchanges/sailing boats/etc. I think it's worth pointing out tjat VDSL is often not available within an exchange here and maybe it's the same in the US. Cheers, James. From morrowc.lists at gmail.com Wed Sep 19 08:31:08 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 19 Sep 2018 01:31:08 -0700 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: <20180919081937.GF14661@vurt.meerval.net> References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180919081937.GF14661@vurt.meerval.net> Message-ID: On Wed, Sep 19, 2018 at 1:19 AM Job Snijders wrote: > On Wed, Sep 19, 2018 at 01:07:42AM -0700, Christopher Morrow wrote: > > > it is about whether it is acceptable that RIRs (and more > > > specifically ARIN in this mailing list's context) notify affected > > > parties of their prefixes that suffer from stale ROAs. > > > > This I still think is a bad plan.. mostly because I don't think it'll > > help :( I think what helps is: "Oh, I cant get to and and > > " .... I think folk that CARE will do the right > > thing, folk that 'think they care' won't and will soon get > > disconnected from the tubez. > > > > I apologize a tad if my view that: "breaking people will force them to > > fix themselves" is .... rough :( > > What about an one-off outreach effort? > > first I'm certainly happy about any progress on the 'RPKI DONE RIGHT' direction, and specifically Job you as a person have made some awesome progress here getting IXP/ISP folk to move to OV and RPKI deployments, and adding RPKI/ROA data into the NTT IRR. but.. I'm skeptical of distinct efforts like this. I think something like (I think these folk still offer this service: "bgp monitoring") BgpMon's monitoring service is what we should aim for: "A service that RPKI users have signed up for" Else: "ends up in spam folder" :( > We need to somehow kickstart the feedback loop, especially if we expect > effects to become forceful. I'm hoping that if the invalid count is low > enough it'll become more attractive for more people flip the switch and > deploy OV. > > Sure.... but: "can not access a majority of the internet?" seems like a good signal to the affected folks. > Kind regards, > > Job > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil.lavin at cloudcall.com Wed Sep 19 08:33:34 2018 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Wed, 19 Sep 2018 08:33:34 +0000 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: <20180919081937.GF14661@vurt.meerval.net> References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180919081937.GF14661@vurt.meerval.net> Message-ID: > What about an one-off outreach effort? Makes sense to me. As someone who (at least pretends to) care, I was very much unaware of RPKI before seeing discussion about it on NANOG and #ix. That said, having recently done this with ARIN... they've got a long way to go before it's a simple process (like RIPE). Submitting numerous tickets over a 3 day period doesn't strike me as particularly efficient. If outreach was done and widely taken up, I'd think ARIN's help desk will struggle to meet the demand. If this is the case and it's a multi-week process to get RPKI set up, it would be expected that people will give up part way through the process. From morrowc.lists at gmail.com Wed Sep 19 08:37:17 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 19 Sep 2018 01:37:17 -0700 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180919081937.GF14661@vurt.meerval.net> Message-ID: On Wed, Sep 19, 2018 at 1:33 AM Phil Lavin wrote: > > What about an one-off outreach effort? > > Makes sense to me. As someone who (at least pretends to) care, I was very > much unaware of RPKI before seeing discussion about it on NANOG and #ix. > > That said, having recently done this with ARIN... they've got a long way > to go before it's a simple process (like RIPE). Submitting numerous tickets > over a 3 day period doesn't strike me as particularly efficient. If > outreach was done and widely taken up, I'd think ARIN's help desk will > struggle to meet the demand. If this is the case and it's a multi-week > process to get RPKI set up, it would be expected that people will give up > part way through the process. > Phil. Thanks, this is interesting input.. I expected that the system arin setup was on-par with that which ripe/apnic have setup... huh, I'm surprised that it required any tickets at all to accomplish :( -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwbensley at gmail.com Wed Sep 19 08:40:45 2018 From: jwbensley at gmail.com (James Bensley) Date: Wed, 19 Sep 2018 09:40:45 +0100 Subject: Console Servers In-Reply-To: References: Message-ID: On Tue, 18 Sep 2018 at 14:38, Alan Hannan wrote: > > I'd like your input on suggestions for an alternate serial port manager. > > Long ago I used Cisco 2511/2611 and was fairly happy. A little later I used portmaster and was less so. Recently I've been using Opengear and they work fairly well but the price is fairly high. I use the CM7100 and IM7100. > > General specs I'm looking for are: > > * 8 to 48 or more rs232 serial ports on rj45 > * nice-to-have software selectable pinouts (cisco v. straight) > * gig-e ethernet port (100mbps ok) > * 1U form factor > * redundant AC power > * access physical serial connections via local port # > * access physical serial connections via local IP alias (nice to have) > > Can you recommend a serial port server/concentrator that I could use in place of opengear for a better value and/or lower cost? > > I'm just ignorant about the current market for serial port concentrators and so far web searches have not revealed ideas, so your input is appreciated! > > Thanks! > > -alan Hi Alan, Ah the trusty Cisco solution - yep, used the 2800 series quite a bit for exactly this, just last year even I was deploying them. 16-32 serial connections for OOB console, an Ethernet port for an OOB IP MGMT switch and VDSL for the WAN connection. You can also use low end Juniper SRX devices for this (SRX200 series) and a cheap console server, I've used SRX + OpenGear (not so cheap) console server just fine. You just need a couple of central firewalls to terminate some IPSEC tunnels (again, cheap SRXs have served fine as the crypto throughput is typically low). Some companies don't deploy anything into production which is not vendor supported, so the 2800s wouldn't fly in that case. We used to buy 2800s off ebay and 2nd hand tin sellers. However, for lab work some companies are more relaxed, this is an example 2800 config that I use for console access in the lab if you want: https://null.53bits.co.uk/index.php?page=hwic-16a-terminal-server I'd be reluctant to deploy Cisco 2800s (or similar) today unless there is a newer variant, is there an ISGv2 variant with serial connectivity that Cisco will be supporting for a few more years? I know OpenGrear are expensive but in my current outfit, they do "just work" and the few we had at my old place, again they did "just work". Cheers, James. From nusenu-lists at riseup.net Wed Sep 19 08:49:00 2018 From: nusenu-lists at riseup.net (nusenu) Date: Wed, 19 Sep 2018 08:49:00 +0000 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> Message-ID: <03354fa9-c045-430a-c4f6-d32f9d313e0c@riseup.net> Christopher Morrow wrote: > This seems bad, at first blush, but you will not always be here to offer > these recalcitrant folk a pointer to how to fix themselves that is correct but I don't expect that (to be around forever) to be necessary, once the amount of invalids are low, big operators could deploy ROV, and once that is the case operators will get an immediate effect should they create incorrect ROAs, which will cause a learning effect. At that point the amount of misconfigured ROAs would automatically remain low because ROV somewhat forces proper ROAs. >> it is about whether it is acceptable that RIRs (and more specifically ARIN >> in this mailing list's context) >> notify affected parties of their prefixes that suffer from stale ROAs. >> > > This I still think is a bad plan.. mostly because I don't think it'll help > :( If such an attempt to make people aware about their broken ROAs has no effect at all but I did no harm, than I'm fine with it because we at least tried. I'm not sure I can follow the "lets not send these 31 emails because it is such a big effort and they will just end up in the spam folder with no effect." line of reasoning. Do you think we would be doing more harm than good by sending out these 31 emails? > I think what helps is: "Oh, I cant get to and and internet>" .... I think folk that CARE will do the right thing, folk that > 'think they care' won't and will soon get disconnected from the tubez. > > I apologize a tad if my view that: "breaking people will force them to fix > themselves" is .... rough :( I believe it would be more polite to tell them first before you force anything on them by enabling ROV, but your way of doing it would certainly be more efficient ;) -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From saku at ytti.fi Wed Sep 19 08:50:15 2018 From: saku at ytti.fi (Saku Ytti) Date: Wed, 19 Sep 2018 11:50:15 +0300 Subject: Console Servers In-Reply-To: References: Message-ID: Hey, > In some DCs I've done mutual OOB swaps with other telcos in the same > suite, this is usually cheap or free (excluding the one time xconnect We consciously decided to not ask or accept OOB swaps, because of fear that they might be provisioned outside processes which might make it impossible to repair them through normal commercial processes, which would potentially cost lot of downtime and NOC's resources. > Sometimes the DC provider has an OOB connectivity service that uses > separate transit providers than we use and this often cheap too. Again > this is often bespoke per DC/colo provider though. MRC quotes I have 400USD Equinix, 288USD Terramark, 300USD Coresite. Compared to PSTN which we see at 90-150USD. This makes me less inclined to focus on HW CAPEX and optimise for HW/SW that tooling and people already support. > The most scalable solution I've been involved in so far is VDSL. Here > in the UK lots of DCs are on-net for the national incumbent VDSL I think WAN indeed is very market situational, and if you need to support world, it is beneficial to have solution which supports many WAN options, without needing external boxes and external power bricks. We try to do just ethernet, but even that is already being provided as copper, fibre and in one market with PPPoE, all which are non-issues by going with Cisco. I do wish I had second option, I do wish JNPR SRX would support async serial ports. -- ++ytti From sc at ottie.org Wed Sep 19 08:51:59 2018 From: sc at ottie.org (Scott Christopher) Date: Wed, 19 Sep 2018 08:51:59 +0000 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> <8A48B84A-7284-43D4-826D-108F9E1EF71C@6by7.net> <3d5f160c-c06c-6b13-0588-e1ee2ddacb30@efes.iucc.ac.il> <08651119-3714-4A53-ADF0-989869253BE9@delong.com> <0D56BF2A-A5F2-4FC5-9E66-F8733AA2BADF@delong.com> Message-ID: <1537347119.1365584.1513179864.4955F30E@webmail.messagingengine.com> Christopher Morrow wrote: > Whether it actually 'costs' that much to pull a x-connect and maintain > that x-connect is probably not as important as 'gosh it's really hard > to be 'close' to ' right? which is what they are > capitalizing on here.> > Hank, how far away is the next closest large network metro ? Riyad? > Rome? Sofia?... I mean, it's all 'far' from 'isreal' (or really any > part of the world) to the next decent network POP :(> I'm not sure if Israelis can buy anything from Riyadh, though. It's usually the case that Israelis and their neighbors can't do business with each other, either because of their neighbor's laws or Israel's laws, or both. So your Tel Aviv data center has a much smaller market and can't benefit from economies of scale like more developed markets such as United States and western Europe which sell globally. I agree that capitalism lets you charge whatever you can get but healthy capitalism gives you competition. The *big* question: If prices are so high in Israel, why don't competitors enter this market when it's 1) pretty much commodity and 2) booming globally? --S.C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwbensley at gmail.com Wed Sep 19 08:54:30 2018 From: jwbensley at gmail.com (James Bensley) Date: Wed, 19 Sep 2018 09:54:30 +0100 Subject: Console Servers In-Reply-To: References: Message-ID: On Tue, 18 Sep 2018 at 15:26, Saku Ytti wrote: > > On Tue, 18 Sep 2018 at 16:39, Alan Hannan wrote: > > > Long ago I used Cisco 2511/2611 and was fairly happy. A little later I used portmaster and was less so. Recently I've been using Opengear and they work fairly well but the price is fairly high. I use the CM7100 and IM7100. > > Out of curiosity, how do you connect them? I see quotes around > 200USD/MRC for ethernet in US, implying 12kUSD 5 year cost on just > connectivity, add rack rental, and power and Opengear price is maybe > 10% of TCO? > > Personally I still prefer Cisco, as not to have new operating system > to automate. Add conserver to connect persistently to each console > port, so that you get persistent logs from console to your NMS, and so > that you can multiplex your console sessions. > It's hard to recover the CAPEX benefit if you need OOB platform > specific OPEX costs. > > -- > ++ytti Hi Saku, I forgot to mention, it also depends how "out" of band your OOB needs to be. We use Ciena 6500s for our DWDM infrastructure and they have a wayside channel (like various DWDM vendors), so it's a separate channel over the same physical fibre. For anything except a fibre cut it seems to work. Cheers, James. From jwbensley at gmail.com Wed Sep 19 09:00:33 2018 From: jwbensley at gmail.com (James Bensley) Date: Wed, 19 Sep 2018 10:00:33 +0100 Subject: Console Servers In-Reply-To: References: Message-ID: On Wed, 19 Sep 2018 at 09:50, Saku Ytti wrote: > I think WAN indeed is very market situational, and if you need to > support world, it is beneficial to have solution which supports many > WAN options, without needing external boxes and external power bricks. > We try to do just ethernet, but even that is already being provided as > copper, fibre and in one market with PPPoE, all which are non-issues > by going with Cisco. I do wish I had second option, I do wish JNPR SRX > would support async serial ports. Agreed, this is where the Cisco's shine. We can insert a mixture of ADSL/VDSL, Ethernet and serial cards into the same box. It's a nice all in one solution that supports all our various OOB connection types and the console connectivity, and we could connect a IP management switch. I mentioned earlier that OOB inside a DC is different to in a telephone exchange, and the OP didn't mention which was required. I forgot to mention that a third kind of OOB is for kit that is outside. If you need temperature hardened and DC powered OOB kit your options dramatically shrink and it's worth considering if you're in that boat. Cheers, James. From saku at ytti.fi Wed Sep 19 09:04:58 2018 From: saku at ytti.fi (Saku Ytti) Date: Wed, 19 Sep 2018 12:04:58 +0300 Subject: Console Servers In-Reply-To: References: Message-ID: On Wed, 19 Sep 2018 at 11:54, James Bensley wrote: > I forgot to mention, it also depends how "out" of band your OOB needs > to be. We use Ciena 6500s for our DWDM infrastructure and they have a > wayside channel (like various DWDM vendors), so it's a separate > channel over the same physical fibre. For anything except a fibre cut > it seems to work. This is gold standard for incumbents, as they don't have anything true out-of-band they can consistently buy, everything travels in their network at some point anyhow. -- ++ytti From nanog at ics-il.net Wed Sep 19 09:21:21 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 19 Sep 2018 04:21:21 -0500 (CDT) Subject: Console Servers In-Reply-To: References: Message-ID: <34343389.5725.1537348880205.JavaMail.mhammett@ThunderFuck> Except for AT&T, most incumbents here aren't also mobile wireless providers, so that is an option in most cases for truly OOB. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Saku Ytti" To: "James Bensley" Cc: nanog at nanog.org Sent: Wednesday, September 19, 2018 4:04:58 AM Subject: Re: Console Servers On Wed, 19 Sep 2018 at 11:54, James Bensley wrote: > I forgot to mention, it also depends how "out" of band your OOB needs > to be. We use Ciena 6500s for our DWDM infrastructure and they have a > wayside channel (like various DWDM vendors), so it's a separate > channel over the same physical fibre. For anything except a fibre cut > it seems to work. This is gold standard for incumbents, as they don't have anything true out-of-band they can consistently buy, everything travels in their network at some point anyhow. -- ++ytti -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at nlnetlabs.nl Wed Sep 19 09:45:24 2018 From: alex at nlnetlabs.nl (Alex Band) Date: Wed, 19 Sep 2018 11:45:24 +0200 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180919081937.GF14661@vurt.meerval.net> Message-ID: <7219FACC-6B09-4DA6-A92D-0C6851A86DED@nlnetlabs.nl> > On 19 Sep 2018, at 10:37, Christopher Morrow wrote: > > > > On Wed, Sep 19, 2018 at 1:33 AM Phil Lavin wrote: > > What about an one-off outreach effort? > >> Makes sense to me. As someone who (at least pretends to) care, I was very much unaware of RPKI before seeing discussion about it on NANOG and #ix. >> >> That said, having recently done this with ARIN... they've got a long way to go before it's a simple process (like RIPE). Submitting numerous tickets over a 3 day period doesn't strike me as particularly efficient. If outreach was done and widely taken up, I'd think ARIN's help desk will struggle to meet the demand. If this is the case and it's a multi-week process to get RPKI set up, it would be expected that people will give up part way through the process. >> > Phil. Thanks, this is interesting input.. I expected that the system arin setup was on-par with that which ripe/apnic have setup... huh, I'm surprised that it required any tickets at all to accomplish :( ARIN offers all of the features that the other RIRs do, but usability remains a (big) barrier. I did a talk at NANOG several years ago demonstrating how usability of the hosted RPKI system greatly impacted adoption and data quality in the RIPE region: https://youtu.be/R2VV_APOFL8 At the time, a lot of effort went into providing a hosted RPKI system that suggested ROAs based on best practices, showed what the impact on BGP announcements was going to be and sent alerts when misconfigurations or hijacks occurred. This gives operators the confidence to use and maintain the system. As a result, the data set is now big and high quality enough for operators to start dropping invalids. I’d be interested to hear how many operators in the ARIN region would be willing to set up ROAs (and maintain them!) if it weren’t so hard to do. This might entice ARIN to address the usability issue. Because non-repudiation or not, this process shouldn’t have to take several tickets and several days. Be that as it may, we fully intend to build a Delegated CA that is on par with RIPE’s user experience so that operators can run RPKI themselves in a usable way. Alex Band NLnet Labs From nusenu-lists at riseup.net Wed Sep 19 09:53:00 2018 From: nusenu-lists at riseup.net (nusenu) Date: Wed, 19 Sep 2018 09:53:00 +0000 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180919081937.GF14661@vurt.meerval.net> Message-ID: <41be6cbd-aaa4-9686-e421-bb32d8c4cf5c@riseup.net> Phil Lavin: > That said, having recently done this with ARIN... they've got a long > way to go before it's a simple process (like RIPE). Submitting > numerous tickets over a 3 day period doesn't strike me as > particularly efficient. > If outreach was done and widely taken up, I just want to reiterate that this is not about an outreach program "Create ROAs for all your prefixes NOW", this is just about notifying those ~30 orgs that have likely misconfigured ROAs that result in unreachable prefixes in an ROV environment. > I'd > think ARIN's help desk will struggle to meet the demand. If this is > the case and it's a multi-week process to get RPKI set up, it would > be expected that people will give up part way through the process. That is a great input, we certainly would not want to cause a bottleneck at ARIN's helpdesk. To avoid overwhelming the help desk, these ~30 organizations could be notified one at a time (i.e. notify 5 organizations per week and be done in a ~month), I assume that is a manageable amount of tickets per day. -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From nanog-post at rsuc.gweep.net Wed Sep 19 12:03:26 2018 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Wed, 19 Sep 2018 08:03:26 -0400 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: <4BDDAFA6-55E3-4FF2-BB74-2D25973E95A3@delong.com> References: <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180918173542.GE58800@vurt.meerval.net> <94EBD5EC-F723-45BC-A6AD-10895E2B8C0E@delong.com> <20180918213457.GA14661@vurt.meerval.net> <4145438B-D18D-44ED-BF7E-575F137E7817@delong.com> <20180918220756.GC14661@vurt.meerval.net> <4BDDAFA6-55E3-4FF2-BB74-2D25973E95A3@delong.com> Message-ID: <20180919120326.GA25153@gweep.net> There's a lot to sift through in this thread (most of all assertions lacking evidence), but this needs to be called out: On Tue, Sep 18, 2018 at 06:21:56PM -0700, Owen DeLong wrote: [snip] > Point being that there are very very few ASNs using peer lock. Peer lock Despite the cutesy neologism, filtering against the acceptance of big/important/private peers's ASNs from unplanned vectors is very common and was a standard part of the belt and suspenders toolkit long, long ago.* When I drove 6079, I distinctly recall it coming up in conversations with representatives from 2828 (it might have been the concentric days) and others in the hallways at NANOG. Cheers, Joe * Barring those who never cared about forwarding quality or path integrity and would say "LOL someone gives me free transit to you". -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling From jcurran at arin.net Wed Sep 19 12:06:00 2018 From: jcurran at arin.net (John Curran) Date: Wed, 19 Sep 2018 12:06:00 +0000 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> Message-ID: <4738F10A-FD77-456E-8D26-584C0F991ED1@arin.net> On 18 Sep 2018, at 1:23 PM, Owen DeLong wrote: > > Personally, since all RPKI accomplishes is providing a cryptographically signed notation of origin ASNs that hijackers should prepend to their announcements in order to create an aura of credibility, I think we should stop throwing resources down this rathole. Owen - Other than use of resources towards an initiative that some operators value (and others do not), is there any reason that notifying RPKI users about invalid prefixes is not a wise idea; i.e. are you aware of any technical downside to doing so? /John John Curran President and CEO ARIN From nusenu-lists at riseup.net Wed Sep 19 16:32:00 2018 From: nusenu-lists at riseup.net (nusenu) Date: Wed, 19 Sep 2018 16:32:00 +0000 Subject: the prefixes that wont be able to reach Cloudflare by the end of the year (unless RPKI ROAs are fixed) Message-ID: Hi, apparently Cloudflare will be enforcing RPKI route origin validation "by the end of the year" [1]. https://blog.cloudflare.com/rpki-details/ If this is actually the case then some prefixes run at risk of loosing the ability to reach Cloudflare. This is a heads-up so you can check if you would be affected, you can ctrl-f the list of 75 prefixes (ARIN region only) bellow for your prefix or ASN. (data as of 2018-09-19 14:06 UTC) https://bgp.he.net/net/168.245.235.0/24 (AS13428) https://bgp.he.net/net/69.28.67.0/24 (AS13768) https://bgp.he.net/net/69.28.82.0/23 (AS13768) https://bgp.he.net/net/68.64.234.0/24 (AS14237) https://bgp.he.net/net/209.24.0.0/24 (AS15562) https://bgp.he.net/net/172.98.214.0/24 (AS17139) https://bgp.he.net/net/66.85.44.0/24 (AS19437) https://bgp.he.net/net/23.139.0.0/24 (AS20860) https://bgp.he.net/net/68.64.227.0/24 (AS262913) https://bgp.he.net/net/192.136.187.0/24 (AS26827) https://bgp.he.net/net/208.76.33.0/24 (AS26938) https://bgp.he.net/net/208.76.39.0/24 (AS26938) https://bgp.he.net/net/68.64.231.0/24 (AS30167) https://bgp.he.net/net/192.133.106.0/24 (AS33060) https://bgp.he.net/net/192.133.107.0/24 (AS33060) https://bgp.he.net/net/192.209.63.0/24 (AS393398) https://bgp.he.net/net/198.28.13.0/24 (AS393451) https://bgp.he.net/net/2606:8e80:3000::/48 (AS394308) https://bgp.he.net/net/2606:8e80:1000::/48 (AS394497) https://bgp.he.net/net/2606:8e80:4000::/48 (AS394497) https://bgp.he.net/net/2606:8e80::/48 (AS394497) https://bgp.he.net/net/2606:8e80:5000::/48 (AS394497) https://bgp.he.net/net/2606:8e80:2000::/48 (AS394644) https://bgp.he.net/net/2606:8e80:4000::/48 (AS394644) https://bgp.he.net/net/104.245.239.0/24 (AS395970) https://bgp.he.net/net/172.98.209.0/24 (AS395970) https://bgp.he.net/net/172.98.210.0/24 (AS395970) https://bgp.he.net/net/172.98.212.0/24 (AS395970) https://bgp.he.net/net/172.98.214.0/24 (AS395970) https://bgp.he.net/net/172.98.215.0/24 (AS395970) https://bgp.he.net/net/172.98.208.0/24 (AS41139) https://bgp.he.net/net/172.98.211.0/24 (AS41139) https://bgp.he.net/net/172.98.213.0/24 (AS41139) https://bgp.he.net/net/168.245.223.0/24 (AS43181) https://bgp.he.net/net/208.84.64.0/24 (AS52129) https://bgp.he.net/net/208.86.200.0/24 (AS52129) https://bgp.he.net/net/199.68.168.0/22 (AS53429) https://bgp.he.net/net/199.68.175.0/24 (AS53429) https://bgp.he.net/net/162.208.108.0/24 (AS55079) https://bgp.he.net/net/162.208.109.0/24 (AS55079) https://bgp.he.net/net/162.208.110.0/24 (AS55079) https://bgp.he.net/net/162.208.111.0/24 (AS55079) https://bgp.he.net/net/198.176.44.0/24 (AS55079) https://bgp.he.net/net/198.176.46.0/24 (AS55079) https://bgp.he.net/net/198.176.47.0/24 (AS55079) https://bgp.he.net/net/2604:a680:2::/48 (AS55079) https://bgp.he.net/net/2604:ab80:2::/48 (AS55079) https://bgp.he.net/net/2604:ab80:5::/48 (AS55079) https://bgp.he.net/net/198.176.45.0/24 (AS55097) https://bgp.he.net/net/2604:a680:4::/48 (AS55097) https://bgp.he.net/net/208.66.204.0/24 (AS6165) https://bgp.he.net/net/208.66.205.0/24 (AS6165) https://bgp.he.net/net/208.66.206.0/24 (AS6165) https://bgp.he.net/net/208.66.207.0/24 (AS6165) https://bgp.he.net/net/74.116.232.0/24 (AS6165) https://bgp.he.net/net/74.116.233.0/24 (AS6165) https://bgp.he.net/net/74.116.234.0/24 (AS6165) https://bgp.he.net/net/74.116.235.0/24 (AS6165) https://bgp.he.net/net/74.116.236.0/24 (AS6165) https://bgp.he.net/net/74.116.237.0/24 (AS6165) https://bgp.he.net/net/74.116.238.0/24 (AS6165) https://bgp.he.net/net/198.24.10.0/24 (AS62541) https://bgp.he.net/net/198.24.11.0/24 (AS62541) https://bgp.he.net/net/104.171.208.0/20 (AS63267) https://bgp.he.net/net/104.171.208.0/24 (AS63267) https://bgp.he.net/net/69.28.64.0/20 (AS6364) https://bgp.he.net/net/69.28.80.0/23 (AS6364) https://bgp.he.net/net/69.28.84.0/23 (AS6364) https://bgp.he.net/net/69.28.86.0/24 (AS6364) https://bgp.he.net/net/69.28.87.0/24 (AS6364) https://bgp.he.net/net/69.28.88.0/23 (AS6364) https://bgp.he.net/net/69.28.88.0/24 (AS6364) https://bgp.he.net/net/69.28.90.0/23 (AS6364) https://bgp.he.net/net/69.28.92.0/22 (AS6364) https://bgp.he.net/net/172.93.121.0/24 (AS8100) https://bgp.he.net/net/66.85.45.0/24 (AS8100) https://bgp.he.net/net/206.53.202.0/24 (AS11492) that is probably supposed to be invalid (DE-CIX Dallas peering LAN? :) [1] https://twitter.com/Jerome_UZ/status/1042433414371205120 -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From brez at brezworks.com Wed Sep 19 17:44:40 2018 From: brez at brezworks.com (Jeremy Bresley) Date: Wed, 19 Sep 2018 13:44:40 -0400 Subject: Console Servers In-Reply-To: References: Message-ID: On 9/19/18 04:40, James Bensley wrote: > On Tue, 18 Sep 2018 at 14:38, Alan Hannan wrote: >> I'd like your input on suggestions for an alternate serial port manager. >> >> Long ago I used Cisco 2511/2611 and was fairly happy. A little later I used portmaster and was less so. Recently I've been using Opengear and they work fairly well but the price is fairly high. I use the CM7100 and IM7100. >> >> General specs I'm looking for are: >> >> * 8 to 48 or more rs232 serial ports on rj45 >> * nice-to-have software selectable pinouts (cisco v. straight) >> * gig-e ethernet port (100mbps ok) >> * 1U form factor >> * redundant AC power >> * access physical serial connections via local port # >> * access physical serial connections via local IP alias (nice to have) >> > Hi Alan, > > I'd be reluctant to deploy Cisco 2800s (or similar) today unless there > is a newer variant, is there an ISGv2 variant with serial connectivity > that Cisco will be supporting for a few more years? I know OpenGrear > are expensive but in my current outfit, they do "just work" and the > few we had at my old place, again they did "just work". The ISR G2s do have several options for async available as do the current generation ISR4Ks. The ISR G2s (1900/2900/3900s) can take the HWIC-8A, HWIC-16A, or SM-32A for 8/16/32 ports (SM-32A only in 2911 and higher due to being a Service Module form factor) Data sheet: https://www.cisco.com/c/en/us/products/collateral/interfaces-modules/1800-2800-3800-series-16-port-async-high-speed-wan-interface-card/product_data_sheet0900aecd80274416.html The ISR G2 routers were all announced for End-of-Sale a while back, the modules for them were also announced recently, but are still available for sale until Feb 2019.  They'll still be supported until Feb 2024. EOL Announcement: https://www.cisco.com/c/en/us/products/collateral/interfaces-modules/network-modules/eos-eol-notice-c51-741231.html The ISR 4Ks have the NIM-16A, NIM-24A, and the SM-X-64A (16/24/64 ports).  The SM-X is only supported in 4331 and higher due to the SM-X form factor, the 16/24 port ones support at least 2 modules in all ISR4Ks even the low-end 4221.  The NIM-16A and the SM-X-64A can use the same cables as the older async modules, the NIM-24A requires the newer low profile cable for 1 of the ports (can use it for all ports). Data sheet: https://www.cisco.com/c/en/us/products/collateral/routers/4000-series-integrated-services-routers-isr/datasheet-c78-739968.html Talk to your favorite SE or partner for more info and pricing. Jeremy Disclaimer, I do work for Cisco, this info is provided to the list as it was requested and hoping to clarify what's available. My personal $0.02: I've also used some of the older Opengear boxes in the past, they're solid, and Opengear are very good with customer suggestions/feedback.  Lantronix SLCs work once you get them configured, but their configuration web interface was intolerably slow (page refreshes would eat whatever you input into a second option box you clicked to change) and their built-in terminal required Java.  Benefit of Opengear is the other "things" you can do with them since they're Linux based (TFTP/syslog/etc). Benefit of a Cisco ISR is they're straight IOS (G2s)/IOS-XE (4Ks) so any configuration tool that can handle a Cisco box can work with them. From lathama at gmail.com Wed Sep 19 18:13:46 2018 From: lathama at gmail.com (Andrew Latham) Date: Wed, 19 Sep 2018 13:13:46 -0500 Subject: Console Servers In-Reply-To: References: Message-ID: Note: newer Lantronix don't require Java for the config interface at all. Also note that you can organize OOBM and in band management with https://guacamole.apache.org/ if needed. On Wed, Sep 19, 2018 at 12:47 PM Jeremy Bresley wrote: > On 9/19/18 04:40, James Bensley wrote: > > On Tue, 18 Sep 2018 at 14:38, Alan Hannan wrote: > >> I'd like your input on suggestions for an alternate serial port manager. > >> > >> Long ago I used Cisco 2511/2611 and was fairly happy. A little later I > used portmaster and was less so. Recently I've been using Opengear and > they work fairly well but the price is fairly high. I use the CM7100 and > IM7100. > >> > >> General specs I'm looking for are: > >> > >> * 8 to 48 or more rs232 serial ports on rj45 > >> * nice-to-have software selectable pinouts (cisco v. straight) > >> * gig-e ethernet port (100mbps ok) > >> * 1U form factor > >> * redundant AC power > >> * access physical serial connections via local port # > >> * access physical serial connections via local IP alias (nice to have) > >> > > Hi Alan, > > > > I'd be reluctant to deploy Cisco 2800s (or similar) today unless there > > is a newer variant, is there an ISGv2 variant with serial connectivity > > that Cisco will be supporting for a few more years? I know OpenGrear > > are expensive but in my current outfit, they do "just work" and the > > few we had at my old place, again they did "just work". > The ISR G2s do have several options for async available as do the > current generation ISR4Ks. > > The ISR G2s (1900/2900/3900s) can take the HWIC-8A, HWIC-16A, or SM-32A > for 8/16/32 ports (SM-32A only in 2911 and higher due to being a Service > Module form factor) > > Data sheet: > > https://www.cisco.com/c/en/us/products/collateral/interfaces-modules/1800-2800-3800-series-16-port-async-high-speed-wan-interface-card/product_data_sheet0900aecd80274416.html > > The ISR G2 routers were all announced for End-of-Sale a while back, the > modules for them were also announced recently, but are still available > for sale until Feb 2019. They'll still be supported until Feb 2024. > > EOL Announcement: > > https://www.cisco.com/c/en/us/products/collateral/interfaces-modules/network-modules/eos-eol-notice-c51-741231.html > > The ISR 4Ks have the NIM-16A, NIM-24A, and the SM-X-64A (16/24/64 > ports). The SM-X is only supported in 4331 and higher due to the SM-X > form factor, the 16/24 port ones support at least 2 modules in all > ISR4Ks even the low-end 4221. The NIM-16A and the SM-X-64A can use the > same cables as the older async modules, the NIM-24A requires the newer > low profile cable for 1 of the ports (can use it for all ports). > > Data sheet: > > https://www.cisco.com/c/en/us/products/collateral/routers/4000-series-integrated-services-routers-isr/datasheet-c78-739968.html > > Talk to your favorite SE or partner for more info and pricing. > > Jeremy > > Disclaimer, I do work for Cisco, this info is provided to the list as it > was requested and hoping to clarify what's available. > > My personal $0.02: I've also used some of the older Opengear boxes in > the past, they're solid, and Opengear are very good with customer > suggestions/feedback. Lantronix SLCs work once you get them configured, > but their configuration web interface was intolerably slow (page > refreshes would eat whatever you input into a second option box you > clicked to change) and their built-in terminal required Java. Benefit > of Opengear is the other "things" you can do with them since they're > Linux based (TFTP/syslog/etc). Benefit of a Cisco ISR is they're > straight IOS (G2s)/IOS-XE (4Ks) so any configuration tool that can > handle a Cisco box can work with them. > > -- - Andrew "lathama" Latham - -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.py at tsisemi.com Wed Sep 19 18:29:15 2018 From: michel.py at tsisemi.com (Michel Py) Date: Wed, 19 Sep 2018 18:29:15 +0000 Subject: the prefixes that wont be able to reach Cloudflare by the end of the year (unless RPKI ROAs are fixed) In-Reply-To: References: Message-ID: <2ef4bd4d719043ceae909cb1d671e36c@CRA110.am.necel.com> > nusenu wrote : > apparently Cloudflare will be enforcing RPKI route origin validation "by the end of the year" [1]. > https://blog.cloudflare.com/rpki-details/ > If this is actually the case then some prefixes run at risk of loosing the ability to reach Cloudflare. This is the way we are going to get people to clean up their invalid prefixes. When people start to actually discard or block them and something breaks. I still think that ARIN should be contacting them, if they are willing to do it. > Phil Lavin wrote : > That said, having recently done this with ARIN... they've got a long way to go before it's a simple process (like RIPE). Submitting numerous tickets over a 3 day period doesn't strike me as particularly efficient. I was wondering if this is the reason ARIN is so far behind RIPE in terms of RPKI adoption. I did not find it bad personally, but I could understand that it may discourage people with a large number of prefixes. There must be something else than the process not being as simple as RIPE's, IMHO. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From webnetwiz at gmail.com Wed Sep 19 06:30:12 2018 From: webnetwiz at gmail.com (David Kotlerewsky) Date: Wed, 19 Sep 2018 06:30:12 +0000 Subject: Console Servers In-Reply-To: References: <3C05F647-002D-4392-B1B1-06D85FCE34DC@netcombb.co.jp>, Message-ID: +++ for Opengear. Manages PDUs and UPS, some models have GPS and 4G LTE options. If additional intelligence is needed for a lights out facility, Uplogix has an interesting solution as well. Sincerely, David K. Sent from my mobile device, please excuse any typos or brevity. ________________________________ From: NANOG on behalf of Erik Sundberg Sent: Tuesday, September 18, 2018 7:27:49 PM To: Jun Tanaka; nanog at nanog.org; Alan Hannan; NANOG Subject: RE: Console Servers Perle IOLAN SCS series is great. We have them all over the United States. From: NANOG On Behalf Of Jun Tanaka Sent: Tuesday, September 18, 2018 10:52 AM To: nanog at nanog.org; Alan Hannan ; NANOG Subject: Re: Console Servers How about SMART CS series by Seiko solutions? https://www.seiko-sol.co.jp/en/products/console-server/ -- Jun Tanaka - NetComBB/S.N.I ________________________________ 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 owen at delong.com Thu Sep 20 00:03:29 2018 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Sep 2018 17:03:29 -0700 Subject: Console Servers In-Reply-To: References: Message-ID: <6C764BFE-7FF4-4843-9590-32A5E562817E@delong.com> > On Sep 19, 2018, at 01:50 , Saku Ytti wrote: > > Hey, > >> In some DCs I've done mutual OOB swaps with other telcos in the same >> suite, this is usually cheap or free (excluding the one time xconnect > > We consciously decided to not ask or accept OOB swaps, because of fear > that they might be provisioned outside processes which might make it > impossible to repair them through normal commercial processes, which > would potentially cost lot of downtime and NOC's resources. > >> Sometimes the DC provider has an OOB connectivity service that uses >> separate transit providers than we use and this often cheap too. Again >> this is often bespoke per DC/colo provider though. > > MRC quotes I have 400USD Equinix, 288USD Terramark, 300USD Coresite. > Compared to PSTN which we see at 90-150USD. This makes me less > inclined to focus on HW CAPEX and optimise for HW/SW that tooling and > people already support. Your PSTN figure doesn’t include the cost of the XC to bring that POTS line into your suite/cage/cabinet. Once you add that in, It looks to me like you probably exceeded the OOB service price in each of the cases quoted above. >> The most scalable solution I've been involved in so far is VDSL. Here >> in the UK lots of DCs are on-net for the national incumbent VDSL > > I think WAN indeed is very market situational, and if you need to > support world, it is beneficial to have solution which supports many > WAN options, without needing external boxes and external power bricks. > We try to do just ethernet, but even that is already being provided as > copper, fibre and in one market with PPPoE, all which are non-issues > by going with Cisco. I do wish I had second option, I do wish JNPR SRX > would support async serial ports. https://opengear.com/products/cm7100-console-server Has SFP network ports. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Sep 20 00:05:36 2018 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Sep 2018 17:05:36 -0700 Subject: Console Servers In-Reply-To: <34343389.5725.1537348880205.JavaMail.mhammett@ThunderFuck> References: <34343389.5725.1537348880205.JavaMail.mhammett@ThunderFuck> Message-ID: <8383BA44-20F4-436D-866B-D230E9E94199@delong.com> Why am I picturing you rigging up a Particle Electron as a dongle to each device you want remote access to? Owen > On Sep 19, 2018, at 02:21 , Mike Hammett wrote: > > Except for AT&T, most incumbents here aren't also mobile wireless providers, so that is an option in most cases for truly OOB. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > From: "Saku Ytti" > To: "James Bensley" > Cc: nanog at nanog.org > Sent: Wednesday, September 19, 2018 4:04:58 AM > Subject: Re: Console Servers > > On Wed, 19 Sep 2018 at 11:54, James Bensley wrote: > > > I forgot to mention, it also depends how "out" of band your OOB needs > > to be. We use Ciena 6500s for our DWDM infrastructure and they have a > > wayside channel (like various DWDM vendors), so it's a separate > > channel over the same physical fibre. For anything except a fibre cut > > it seems to work. > > This is gold standard for incumbents, as they don't have anything true > out-of-band they can consistently buy, everything travels in their > network at some point anyhow. > > -- > ++ytti -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Thu Sep 20 00:06:53 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 19 Sep 2018 19:06:53 -0500 (CDT) Subject: Console Servers In-Reply-To: <8383BA44-20F4-436D-866B-D230E9E94199@delong.com> References: <34343389.5725.1537348880205.JavaMail.mhammett@ThunderFuck> <8383BA44-20F4-436D-866B-D230E9E94199@delong.com> Message-ID: <1163684272.6757.1537402010739.JavaMail.mhammett@ThunderFuck> There's always the WOOBM! https://mikrotik.com/product/woobm ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Owen DeLong" To: "Mike Hammett" Cc: "Saku Ytti" , nanog at nanog.org Sent: Wednesday, September 19, 2018 7:05:36 PM Subject: Re: Console Servers Why am I picturing you rigging up a Particle Electron as a dongle to each device you want remote access to? Owen On Sep 19, 2018, at 02:21 , Mike Hammett < nanog at ics-il.net > wrote: Except for AT&T, most incumbents here aren't also mobile wireless providers, so that is an option in most cases for truly OOB. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Saku Ytti" < saku at ytti.fi > To: "James Bensley" < jwbensley at gmail.com > Cc: nanog at nanog.org Sent: Wednesday, September 19, 2018 4:04:58 AM Subject: Re: Console Servers On Wed, 19 Sep 2018 at 11:54, James Bensley wrote: > I forgot to mention, it also depends how "out" of band your OOB needs > to be. We use Ciena 6500s for our DWDM infrastructure and they have a > wayside channel (like various DWDM vendors), so it's a separate > channel over the same physical fibre. For anything except a fibre cut > it seems to work. This is gold standard for incumbents, as they don't have anything true out-of-band they can consistently buy, everything travels in their network at some point anyhow. -- ++ytti -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Sep 20 00:20:35 2018 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Sep 2018 17:20:35 -0700 Subject: the prefixes that wont be able to reach Cloudflare by the end of the year (unless RPKI ROAs are fixed) In-Reply-To: References: Message-ID: Note to self… It’s better not to do RPKI than to do it badly. Owen > On Sep 19, 2018, at 09:32 , nusenu wrote: > > Hi, > > apparently Cloudflare will be enforcing RPKI route origin validation > "by the end of the year" [1]. > > https://blog.cloudflare.com/rpki-details/ > > If this is actually the case then some prefixes run at risk of loosing > the ability to reach Cloudflare. > > This is a heads-up so you can check if you would be affected, > you can ctrl-f the list of 75 prefixes (ARIN region only) > bellow for your prefix or ASN. > > (data as of 2018-09-19 14:06 UTC) > > > https://bgp.he.net/net/168.245.235.0/24 (AS13428) > https://bgp.he.net/net/69.28.67.0/24 (AS13768) > https://bgp.he.net/net/69.28.82.0/23 (AS13768) > https://bgp.he.net/net/68.64.234.0/24 (AS14237) > https://bgp.he.net/net/209.24.0.0/24 (AS15562) > https://bgp.he.net/net/172.98.214.0/24 (AS17139) > https://bgp.he.net/net/66.85.44.0/24 (AS19437) > https://bgp.he.net/net/23.139.0.0/24 (AS20860) > https://bgp.he.net/net/68.64.227.0/24 (AS262913) > https://bgp.he.net/net/192.136.187.0/24 (AS26827) > https://bgp.he.net/net/208.76.33.0/24 (AS26938) > https://bgp.he.net/net/208.76.39.0/24 (AS26938) > https://bgp.he.net/net/68.64.231.0/24 (AS30167) > https://bgp.he.net/net/192.133.106.0/24 (AS33060) > https://bgp.he.net/net/192.133.107.0/24 (AS33060) > https://bgp.he.net/net/192.209.63.0/24 (AS393398) > https://bgp.he.net/net/198.28.13.0/24 (AS393451) > https://bgp.he.net/net/2606:8e80:3000::/48 (AS394308) > https://bgp.he.net/net/2606:8e80:1000::/48 (AS394497) > https://bgp.he.net/net/2606:8e80:4000::/48 (AS394497) > https://bgp.he.net/net/2606:8e80::/48 (AS394497) > https://bgp.he.net/net/2606:8e80:5000::/48 (AS394497) > https://bgp.he.net/net/2606:8e80:2000::/48 (AS394644) > https://bgp.he.net/net/2606:8e80:4000::/48 (AS394644) > https://bgp.he.net/net/104.245.239.0/24 (AS395970) > https://bgp.he.net/net/172.98.209.0/24 (AS395970) > https://bgp.he.net/net/172.98.210.0/24 (AS395970) > https://bgp.he.net/net/172.98.212.0/24 (AS395970) > https://bgp.he.net/net/172.98.214.0/24 (AS395970) > https://bgp.he.net/net/172.98.215.0/24 (AS395970) > https://bgp.he.net/net/172.98.208.0/24 (AS41139) > https://bgp.he.net/net/172.98.211.0/24 (AS41139) > https://bgp.he.net/net/172.98.213.0/24 (AS41139) > https://bgp.he.net/net/168.245.223.0/24 (AS43181) > https://bgp.he.net/net/208.84.64.0/24 (AS52129) > https://bgp.he.net/net/208.86.200.0/24 (AS52129) > https://bgp.he.net/net/199.68.168.0/22 (AS53429) > https://bgp.he.net/net/199.68.175.0/24 (AS53429) > https://bgp.he.net/net/162.208.108.0/24 (AS55079) > https://bgp.he.net/net/162.208.109.0/24 (AS55079) > https://bgp.he.net/net/162.208.110.0/24 (AS55079) > https://bgp.he.net/net/162.208.111.0/24 (AS55079) > https://bgp.he.net/net/198.176.44.0/24 (AS55079) > https://bgp.he.net/net/198.176.46.0/24 (AS55079) > https://bgp.he.net/net/198.176.47.0/24 (AS55079) > https://bgp.he.net/net/2604:a680:2::/48 (AS55079) > https://bgp.he.net/net/2604:ab80:2::/48 (AS55079) > https://bgp.he.net/net/2604:ab80:5::/48 (AS55079) > https://bgp.he.net/net/198.176.45.0/24 (AS55097) > https://bgp.he.net/net/2604:a680:4::/48 (AS55097) > https://bgp.he.net/net/208.66.204.0/24 (AS6165) > https://bgp.he.net/net/208.66.205.0/24 (AS6165) > https://bgp.he.net/net/208.66.206.0/24 (AS6165) > https://bgp.he.net/net/208.66.207.0/24 (AS6165) > https://bgp.he.net/net/74.116.232.0/24 (AS6165) > https://bgp.he.net/net/74.116.233.0/24 (AS6165) > https://bgp.he.net/net/74.116.234.0/24 (AS6165) > https://bgp.he.net/net/74.116.235.0/24 (AS6165) > https://bgp.he.net/net/74.116.236.0/24 (AS6165) > https://bgp.he.net/net/74.116.237.0/24 (AS6165) > https://bgp.he.net/net/74.116.238.0/24 (AS6165) > https://bgp.he.net/net/198.24.10.0/24 (AS62541) > https://bgp.he.net/net/198.24.11.0/24 (AS62541) > https://bgp.he.net/net/104.171.208.0/20 (AS63267) > https://bgp.he.net/net/104.171.208.0/24 (AS63267) > https://bgp.he.net/net/69.28.64.0/20 (AS6364) > https://bgp.he.net/net/69.28.80.0/23 (AS6364) > https://bgp.he.net/net/69.28.84.0/23 (AS6364) > https://bgp.he.net/net/69.28.86.0/24 (AS6364) > https://bgp.he.net/net/69.28.87.0/24 (AS6364) > https://bgp.he.net/net/69.28.88.0/23 (AS6364) > https://bgp.he.net/net/69.28.88.0/24 (AS6364) > https://bgp.he.net/net/69.28.90.0/23 (AS6364) > https://bgp.he.net/net/69.28.92.0/22 (AS6364) > https://bgp.he.net/net/172.93.121.0/24 (AS8100) > https://bgp.he.net/net/66.85.45.0/24 (AS8100) > https://bgp.he.net/net/206.53.202.0/24 (AS11492) that is probably supposed to be invalid (DE-CIX Dallas peering LAN? :) > > > [1] https://twitter.com/Jerome_UZ/status/1042433414371205120 > > -- > https://twitter.com/nusenu_ > https://mastodon.social/@nusenu > From owen at delong.com Thu Sep 20 00:55:11 2018 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Sep 2018 17:55:11 -0700 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: References: <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180918173542.GE58800@vurt.meerval.net> <94EBD5EC-F723-45BC-A6AD-10895E2B8C0E@delong.com> <20180918213457.GA14661@vurt.meerval.net> <4145438B-D18D-44ED-BF7E-575F137E7817@delong.com> <20180918220756.GC14661@vurt.meerval.net> <4BDDAFA6-55E3-4FF2-BB74-2D25973E95A3@delong.com> Message-ID: > On Sep 18, 2018, at 21:29 , Christopher Morrow wrote: > > > > On Tue, Sep 18, 2018 at 6:22 PM Owen DeLong > wrote: > > > > On Sep 18, 2018, at 15:07 , Job Snijders > wrote: > > > > On Tue, Sep 18, 2018 at 02:44:30PM -0700, Owen DeLong wrote: > >> ROAs are useful for one hop level validation. At the second AS hop > >> they are 100% useless. > > > > This conversation cannot be had without acknowledging there are multiple > > layers of defense in securing BGP. We should also acknowledge that the > > majority of Internet traffic passes over AS_PATHs that are only one hop. > > Networks that exchange significant amounts of traffic, tend to peer > > directly with each other. > > Actually, I don’t buy that at all. > > Without going into too much detail, I know of at least one former employer who is quite > well peered, distributes a great deal of traffic and sends a tremendous amount of it > via multiple ASNs. > > > an IP resource holder can sign multiple ROA for a single prefix, it's perfectly valid to have: > 157.130.0.0/16 AS112 > 157.130.0.0/16 AS113 > 157.130.0.0/16 AS701 I did not mean that they originate the traffic from multiple ASNs, I mean that a tremendous amount of their traffic goes origin->ASHOP1->ASHOP2->…->END USER. > So 'peered well via multiple ASN isn't really a problem here'. Are you making an argument of the form: "1% of the problems are not solved so this solution can't possibly work” ? Except you misunderstood my meaning. Perhaps my fault, but hopefully the above clarification helps you see my point. > Using ROA from the RPKI system tied through/to the IRR data and applied as filters on the bgp sessions of a network should provide that ASN with more assurance that they will not accept and propagate a route hijack or mistake. Adding in validation is nice as well, and may allow you to be a little less diligent about route filtering... I think more than 1 protection is a good plan though (OV + filters seems sane to me, especially in a world where you can automate that whole lot) Again, unless you can trust the data in the IRR to build a complete list of valid AS Paths from the ORIGIN, you can’t safely reject a fake route that has the correct prepend. The ability to do that strikes me as questionable at best in the vast majority of cases. > >>> In other words, RPKI and the Prefix-to-AS validation procedure give > >>> us much more definitive inputs for routing policies compared to what > >>> can be derived from the IRR. > >> > >> Please explain to me how you distinguish good from bad in the > >> following scenario… You peer with AS6939. You receive routes for > >> 2001:db8:f300::/48 with the following AS Paths > >> > >> 1. 6939 1239 54049 2312 1734 > >> 2. 6939 44046 12049 174 1734 > >> > >> Which one is valid? Which one is not? How did the ROA tell you this? > > > > Both path 1 and 2 are invalid, because of peerlock we'd never accept > > 1239 behind 6939, or 174 behind 6939. AS_PATH filtering combined with > > Origin Validation is where the magic is. > > OK, poor examples crafted at random. Point is there are plenty of valid AS Paths > out there that you can’t actually validate. > > I think Job's point is that there really are note that many... perhaps that's an NTT particular view? I know that my production network's view is similar in 'shorter as paths'. I expect that in large-isp-land it's more prevalent than not. Presuming s/note/not/ I suspect there might be some validity to that viewpoint for supposed “Tier 1” networks. Once you hit Tier 2 and consider their subscribers in the mix, it gets a lot fuzzier and less likely that it is a valid perspective. For the average eyeball network, I bet it’s a complete non-starter. > > >>> RPKI is useful in context of a defense in depth strategy. If one > >>> combines "peerlock" AS_PATH filters with origin validation the end > >>> result is bullet proof. Even if NTT is the only one to deploy this > >>> combination, the benefits are notable. > >> > >> Indeed, if peerlock gets wider deployment, it might prove useful. But > >> unless I’m really misunderstanding peerlock, I don’t see that RPKI > >> brings much else to the table in addition. > > > > Wide deployment is not relevant, this is a unilateral defense mechanism, > > so I fear there may indeed be a degree of misunderstanding. > > Point being that there are very very few ASNs using peer lock. Peer lock > alone AIUI pretty well covers the issue. RPKI provides very little (if any) > verification. > > > I suppose if you are happy just doing peer lock on/for your network and customers then cool! > The RPKI system isn't being forced on you. It seems like a helpful addition to me, but that may not be your outlook. Actually, from my perspective, neither one is practical/useful due to the lack of supporting data to achieve it. My perspective, however, is closer to the eyeball these days, so YMMV at the core. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Sep 20 00:58:49 2018 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Sep 2018 17:58:49 -0700 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: <20180919074457.GD14661@vurt.meerval.net> References: <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180918173542.GE58800@vurt.meerval.net> <94EBD5EC-F723-45BC-A6AD-10895E2B8C0E@delong.com> <20180918215820.GB14661@vurt.meerval.net> <20180919074457.GD14661@vurt.meerval.net> Message-ID: <0FDC9640-E4BA-412B-92EB-297ED6CACF09@delong.com> > On Sep 19, 2018, at 00:44 , Job Snijders wrote: > > On Tue, Sep 18, 2018 at 06:18:00PM -0700, Owen DeLong wrote: >> That depends. If you ONLY allow the maintainer of NET-192.159.10.0/24 >> to update the route objects for it, then the word ONLY is effectively >> present by the lack of any other route objects. > > Ah, so you are now applying the RPKI Origin Validation procedure to a > non-existent flavor of IRR? :-) > > Today I can create route-objects covering 192.159.10.0/24 in a number of > IRR databases and there is nothing you can do to prevent that, this > simply is not the case with RPKI. I prefer an existing system (RPKI) > over hypotheticals (Owen's IRR). > > Secondly, I've also noticed you only emphasize an adversarial angle > (origin spoofing), but there are other angles too. > > The majority of today's BGP problems are attributable to operator > mistakes (misconfigurations). Analysis has shown that most BGP incidents > happen on weekdays rather than in the weekend. The number keys on our > keyboards are quite close to each other and Origin Validation is very > effective against typos. Another angle is bugs in BGP implementations: > your neighbors doing origin validation reduces the impact and > propagation of incorrect announcements from your network should you run > into a software defect. Sure, but given the email thread that started this all, if people start enforcing RPKI based origin validation, do you think it will create fewer or more mistakes in this regard? It appears to me that the complexity of RPKI and other issues will lead to RPKI causing more human-factors based routing accidents than it will likely prevent. >> So RPKI is great if we can just reduce the internet diameter to 1 > > Agreed, in other words: RPKI is offers tangible benefits to those that > peer directly with each other, or use peerlock. Agreed, noting the assumptions built into the theory that everyone can use peerlock. >> in which case MD5 passwords on your BGP sessions pretty much >> accomplishes the same thing with a lot less kerfuffle. > > Uhh... you may want to refresh your memory on what BGP is and how > TCP-MD5 works. Admittedly, it doesn’t cover the fat finger cases above, but, it does cover the “know who you’re accepting the route from” issue for one hop out and in a way that doesn’t allow you to create a time-bomb that becomes visible on a delayed basis when you fat-finger it. Owen From michel.py at tsisemi.com Thu Sep 20 01:00:04 2018 From: michel.py at tsisemi.com (Michel Py) Date: Thu, 20 Sep 2018 01:00:04 +0000 Subject: the prefixes that wont be able to reach Cloudflare by the end of the year (unless RPKI ROAs are fixed) In-Reply-To: References: Message-ID: > Owen DeLong wrote : > Note to self… It’s better not to do RPKI than to do it badly. Not worse than IRR entries or SSL certificates. If you mess it up, resource will go down. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From jared at puck.nether.net Thu Sep 20 01:02:18 2018 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 19 Sep 2018 21:02:18 -0400 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: References: <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180918173542.GE58800@vurt.meerval.net> <94EBD5EC-F723-45BC-A6AD-10895E2B8C0E@delong.com> <20180918213457.GA14661@vurt.meerval.net> <4145438B-D18D-44ED-BF7E-575F137E7817@delong.com> <20180918220756.GC14661@vurt.meerval.net> <4BDDAFA6-55E3-4FF2-BB74-2D25973E95A3@delong.com> Message-ID: > On Sep 19, 2018, at 8:55 PM, Owen DeLong wrote: > > Actually, from my perspective, neither one is practical/useful due to the lack of supporting data to achieve it. I suggest you look at some of the cool research that was done with various prefixes from different regions. You can see the problem with ARIN prefixes fairly easily and how they’re harder to secure as a result. This seems to be broken by design on the part of ARIN based on my limited experiences interacting with the community folk. https://nlnog.net/static/nlnogday2018/8_Measuring_RPKI_ben_NLNOG_2018.pdf And the video here: https://www.youtube.com/watch?v=uDIQDpGObdc It’s super interesting to see which RIR prefixes perform better when it comes to the same security technology. - Jared From owen at delong.com Thu Sep 20 01:02:27 2018 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Sep 2018 18:02:27 -0700 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> Message-ID: <215E915B-2D59-49FB-B43C-0761D5EB41BC@delong.com> > On Sep 19, 2018, at 00:46 , nusenu wrote: > > Owen DeLong: >> Personally, since all RPKI accomplishes is providing a >> cryptographically signed notation of origin ASNs that hijackers >> should prepend to their announcements in order to create an aura of >> credibility, I think we should stop throwing resources down this >> rathole. > > regardless of how one might think about RPKI, there are ROAs out > there that reduce the visibility/reachability of certain prefixes and the > general assumption is that announced prefixes would like to be reachable > even if the operator doesn't care about RPKI and ROAs from the past anymore, he most likely cares > about reachability from a pure operational point of view. Yep… And the easy recipe for one which doesn’t care about RPKI to restore reachability is “delete the ROAs”. > my email was not about: "How much does one like RPKI?” I have no impression that it was. I thought it was about “Should we consume more RIR resources dealing with this additional pain likely to be caused by RPKI?” > it is about whether it is acceptable that RIRs (and more specifically ARIN in this mailing list's context) > notify affected parties of their prefixes that suffer from stale ROAs. I agree with Mr. Morrow that this would end in pain. > Even if one dislikes RPKI entirely the opinion could still be "yes notifying those parties makes sense > to restore reachability”. Agreed. However, whether I liked RPKI or not, I’d still say that notification by the RIRs is prone to sadness. My initial intent was merely to state that I prefer the RIRs not waste additional resources on this, including notification. Owen From owen at delong.com Thu Sep 20 01:03:40 2018 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Sep 2018 18:03:40 -0700 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: <20180919081937.GF14661@vurt.meerval.net> References: <57069000-4623-6409-3d94-8ecad4fe5be0@riseup.net> <1939df17-175e-d574-1fdf-2ab58a4c2182@arin.net> <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180919081937.GF14661@vurt.meerval.net> Message-ID: Looks like a certain CDN has volunteered to do that for you. Owen > On Sep 19, 2018, at 01:19 , Job Snijders wrote: > > On Wed, Sep 19, 2018 at 01:07:42AM -0700, Christopher Morrow wrote: >>> it is about whether it is acceptable that RIRs (and more >>> specifically ARIN in this mailing list's context) notify affected >>> parties of their prefixes that suffer from stale ROAs. >> >> This I still think is a bad plan.. mostly because I don't think it'll >> help :( I think what helps is: "Oh, I cant get to and and >> " .... I think folk that CARE will do the right >> thing, folk that 'think they care' won't and will soon get >> disconnected from the tubez. >> >> I apologize a tad if my view that: "breaking people will force them to >> fix themselves" is .... rough :( > > What about an one-off outreach effort? > > We need to somehow kickstart the feedback loop, especially if we expect > effects to become forceful. I'm hoping that if the invalid count is low > enough it'll become more attractive for more people flip the switch and > deploy OV. > > Kind regards, > > Job From owen at delong.com Thu Sep 20 01:10:36 2018 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Sep 2018 18:10:36 -0700 Subject: the prefixes that wont be able to reach Cloudflare by the end of the year (unless RPKI ROAs are fixed) In-Reply-To: References: Message-ID: Yep… It’s also better not to do SSL or IRR entries than to do it badly. Agreed. Owen > On Sep 19, 2018, at 18:00 , Michel Py wrote: > >> Owen DeLong wrote : >> Note to self… It’s better not to do RPKI than to do it badly. > > Not worse than IRR entries or SSL certificates. If you mess it up, resource will go down. > > Michel. > > TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From owen at delong.com Thu Sep 20 01:13:39 2018 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Sep 2018 18:13:39 -0700 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> <8A48B84A-7284-43D4-826D-108F9E1EF71C@6by7.net> <3d5f160c-c06c-6b13-0588-e1ee2ddacb30@efes.iucc.ac.il> <08651119-3714-4A53-ADF0-989869253BE9@delong.com> <0D56BF2A-A5F2-4FC5-9E66-F8733AA2BADF@delong.com> Message-ID: > On Sep 19, 2018, at 00:44 , Christopher Morrow wrote: > > > > On Tue, Sep 18, 2018 at 12:28 PM Owen DeLong > wrote: > > I’d argue that the difference between reasonable (≤$500 one-time and ≤$50 MRC) and $300 MRC is within range of argument, but I cannot see any way in which an argument can be made that $5840 MRC is not a distortion in that same circumstance. > > > captive audiences (or those which view themselves as captive) are so much fun... :( > I imagine that 'away from Telaviv' in the 20ms arena is .... actually pretty hard to find, right? > If you wanted to offer 'local' content locally (and offer it quickly/fastly (ha!)) it's probably pretty hard in that part of the world, right? Whether it actually 'costs' that much to pull a x-connect and maintain that x-connect is probably not as important as 'gosh it's really hard to be 'close' to ' right? which is what they are capitalizing on here. > > Hank, how far away is the next closest large network metro ? Riyad? Rome? Sofia?... I mean, it's all 'far' from 'isreal' (or really any part of the world) to the next decent network POP :( > At those prices, it doesn’t take a lot of XCs to justify the cost of building an additional datacenter. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Thu Sep 20 02:18:43 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 20 Sep 2018 04:18:43 +0200 Subject: SAFNOG-4/EANOG/tzNOG: 4 Days To Go! Message-ID: Hi all. With just about 4 days to go until the 4th edition of the SAFNOG meeting, in collaboration with EANOG and tzNOG, we are geared for an exciting week in warm & sunny Dar Es Salaam. The agenda will cover key topics for the region, such as: * Is Africa's continued telecommunications investment into Europe wise for the continent? * Data centre infrastructure development in the region. * What the recent IRR changes at RIPE mean for Africa. * The advances of IPv4 brokers into Africa, using AFRINIC very own resources in doing so. * e.t.c. More details about the meeting, registration, venue and agenda at:     http://www.safnog.org/ If you haven't yet, please register your attendance to join us next week. We look forward to seeing you all there. Cheers, Mark Tinka On Behalf of the SAFNOG-4/EANOG/tzNOG Organizing Committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From jheitz at cisco.com Thu Sep 20 05:22:20 2018 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Thu, 20 Sep 2018 05:22:20 +0000 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes Message-ID: <226e83c2ddcc44238c1e2806361d65d6@XCH-ALN-014.cisco.com> Owen, You are correct in that RPKI leaves many problems unsolved. One that it does solve is prefix splitting. If I issue a ROA for prefix 10.1.2.0/23, any announcement of 10.1.2.0/24 (including mine) will be declared INVALID, because that announcement is covered by the ROA and the mask length is longer than maxlen. Of course, as you rightly point out, if I do NOT announce that prefix myself, then anyone is free to announce it anywhere and have it declared VALID just by prepending my ASN. Regards, Jakob. -----Original Message----- Date: Tue, 18 Sep 2018 14:18:55 -0700 From: Owen DeLong What does RPKI offer other than a way to know what to spoof in a prepend for your forged announcement? From andrew.a at awarecorp.co.za Thu Sep 20 14:00:00 2018 From: andrew.a at awarecorp.co.za (Andrew Ashley) Date: Thu, 20 Sep 2018 14:00:00 +0000 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: <20180918155859.GA12055@sunf10.rd.bbc.co.uk> References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> <8A48B84A-7284-43D4-826D-108F9E1EF71C@6by7.net> <3d5f160c-c06c-6b13-0588-e1ee2ddacb30@efes.iucc.ac.il> <1537258775.1572455.1511822440.6AE51233@webmail.messagingengine.com> <20180918155859.GA12055@sunf10.rd.bbc.co.uk> Message-ID: <63F1BA1C-F91A-4227-905B-32D9250DB47D@awarecorp.co.za> > Equinix were a leader in bringing this to the UK, they have said they > want to get the UK charges to US levels (so >10x increase still to > come). US pricing already matches metro waves so we face paying > twice the cost of the wave to the DCs for the short interconnects. Our Internap (reselling Equinix) xconnects at Equinix in Ashburn recently jumped from $250 MRC to $350 overnight. According to the Equinix account manager, their "standard" increase is only 5% p.a. In my experience, US facility MRC's are (generally) always x times more expensive than European equivalent, if there is even an MRC although maybe that is changing as others have mentioned. I guess you could also draw somewhat similar comparisons with IX business models between the US and Europe (commercial vs mutual). > They started charging but I can't attribute >the growing empty rack space to that, more likely AWS is the cause of >that and a driver for increasing xcon fees to make up revenue. > > brandon Agreed. This is a topic worthy of discussion all on its own! Wonder how much of colo/DC operator space and revenue public cloud is eating in 2018? Regards, Andrew. From baldur.norddahl at gmail.com Thu Sep 20 16:56:43 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 20 Sep 2018 18:56:43 +0200 Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: References: <67335e35-d267-fd01-5e79-13de25711f20@arin.net> <30d270151c954c5aa98e7be39b6c9fb5@CAS01ASH.corp.arin.net> <4322379F-E1BB-4CF9-A85D-FDD41305ABF3@arin.net> <73B80FFE-2D5A-41D6-98AA-97295C54F385@delong.com> <20180918173542.GE58800@vurt.meerval.net> <94EBD5EC-F723-45BC-A6AD-10895E2B8C0E@delong.com> <20180918213457.GA14661@vurt.meerval.net> <4145438B-D18D-44ED-BF7E-575F137E7817@delong.com> <20180918220756.GC14661@vurt.meerval.net> <4BDDAFA6-55E3-4FF2-BB74-2D25973E95A3@delong.com> Message-ID: tor. 20. sep. 2018 02.56 skrev Owen DeLong : > > Again, unless you can trust the data in the IRR to build a complete list > of valid AS Paths from the ORIGIN, you can’t safely reject a fake route > that has the correct prepend. > Or you can have each hob validate. For example if HE.net did RPKI validation, it would be effective due to their large number of peerings. If my network has HE.net as one of my uplinks, someone might fake the route via one of my other uplinks, but we would not pick that route due to longer AS path. Regards Baldur -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlm at pixelgate.net Thu Sep 20 17:16:47 2018 From: mlm at pixelgate.net (Mark Milhollan) Date: Thu, 20 Sep 2018 10:16:47 -0700 (PDT) Subject: Reaching out to ARIN members about their RPKI INVALID prefixes In-Reply-To: <226e83c2ddcc44238c1e2806361d65d6@XCH-ALN-014.cisco.com> References: <226e83c2ddcc44238c1e2806361d65d6@XCH-ALN-014.cisco.com> Message-ID: Seems to me that another logical way to work on cleaning-up invalids would be for those that want to perform validation to contact their direct peers with invalids, though even those contacts can become stale there will be some that are still valid and usually involve those intimately interested in routing (peering) problems they might otherwise cause and with the ability to get them fixed. /mark From alan at routingloop.com Fri Sep 21 02:11:48 2018 From: alan at routingloop.com (Alan Hannan) Date: Thu, 20 Sep 2018 21:11:48 -0500 Subject: overages for power usage Message-ID: What kind of typical overage costs have you seen when a customer/you use more than you've committed to? I'm especially interested in datacenter power situations, where maybe you sign up for 5kw or 500kw and use more than that in a given month. Is it billed at the same rate? Is it billed at a higher rate? What's the % increase of the higher rate versus the regular rate? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From baldur.norddahl at gmail.com Fri Sep 21 06:33:32 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 21 Sep 2018 08:33:32 +0200 Subject: overages for power usage In-Reply-To: References: Message-ID: The fuses might match what you ordered. If you go over you might lose power due to a blown fuse. When there is A and B power for redundancy, you need to make sure that one side can take the whole load without blowing any fuses. Otherwise you have no redundancy. Regards Baldur fre. 21. sep. 2018 04.12 skrev Alan Hannan : > What kind of typical overage costs have you seen when a customer/you use > more than you've committed to? > > I'm especially interested in datacenter power situations, where maybe you > sign up for 5kw or 500kw and use more than that in a given month. Is it > billed at the same rate? Is it billed at a higher rate? What's the % > increase of the higher rate versus the regular rate? > > Thanks! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil.lavin at cloudcall.com Fri Sep 21 08:04:04 2018 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Fri, 21 Sep 2018 08:04:04 +0000 Subject: overages for power usage In-Reply-To: References: Message-ID: > What kind of typical overage costs have you seen when a customer/you use more than you've committed to? Telehouse London is 0.75 (GBP) per KWH of overage. Obviously it will depend on datacentre/country. Telehouse increase this annually at 2% above inflation measured against the RPI (last increase was 5.27%) From kenny.taylor at kccd.edu Fri Sep 21 13:56:27 2018 From: kenny.taylor at kccd.edu (Kenny Taylor) Date: Fri, 21 Sep 2018 13:56:27 +0000 Subject: overages for power usage In-Reply-To: References: Message-ID: We would typically order a 20 or 30-amp 208v circuit per rack for a flat fee then install a metered PDU to make sure we didn’t overload it. The flat fee per-circuit seems pretty standard in the US. Using your own metered PDU would help predict the usage if you’re being billed by kWH. Kenny From: NANOG On Behalf Of Baldur Norddahl Sent: Thursday, September 20, 2018 11:34 PM To: nanog at nanog.org Subject: Re: overages for power usage The fuses might match what you ordered. If you go over you might lose power due to a blown fuse. When there is A and B power for redundancy, you need to make sure that one side can take the whole load without blowing any fuses. Otherwise you have no redundancy. Regards Baldur fre. 21. sep. 2018 04.12 skrev Alan Hannan >: What kind of typical overage costs have you seen when a customer/you use more than you've committed to? I'm especially interested in datacenter power situations, where maybe you sign up for 5kw or 500kw and use more than that in a given month. Is it billed at the same rate? Is it billed at a higher rate? What's the % increase of the higher rate versus the regular rate? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at nova8.com Fri Sep 21 13:56:54 2018 From: greg at nova8.com (Greg Elliott) Date: Fri, 21 Sep 2018 08:56:54 -0500 Subject: overages for power usage In-Reply-To: References: Message-ID: If we saw a dc customer approaching their power limit we would typically have a conversation or message them to make sure they were aware. If they anticipated needing more sustained power we would update their agreement accordingly. Sometimes it would be a one-time occurrence so we would typically let it slide. If they needed additional power usually it was in 10 Amps per cabinet or 5-10kW increments if in a larger footprint (cage or suite). We typically did not punish our customers for overages because we wanted them to continue to grow with us and we had the additional power capacity available. Some colo providers will put a premium on power overages 5-50% (I have seen all over the board) in order to make additional revenue on power spikes, make the customer more accountable to staying within their power commit or maybe the power is limited at that dc or on that floor. Hope this helps. Feel free to call with additional questions - 816-213-7731. Greg On Thu, Sep 20, 2018 at 9:13 PM Alan Hannan wrote: > What kind of typical overage costs have you seen when a customer/you use > more than you've committed to? > > I'm especially interested in datacenter power situations, where maybe you > sign up for 5kw or 500kw and use more than that in a given month. Is it > billed at the same rate? Is it billed at a higher rate? What's the % > increase of the higher rate versus the regular rate? > > Thanks! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lee at stratacore.com Fri Sep 21 15:15:47 2018 From: lee at stratacore.com (Lee Pallat) Date: Fri, 21 Sep 2018 15:15:47 +0000 Subject: overages for power usage In-Reply-To: References: Message-ID: We see lots of different approaches to this, depending on the datacenter operator: 1. Customer pays for power overage at an agreed to rate that is usually the same as their committed rate (but could be more). This could be based on a: * Per KW consumed * Per KWh consumed * Per Amp consumed 1. Customer is notified that they are over their committed draw, and asked to increase their commitment. Could be: * Immediately * After a few months of repeated overages 1. Nothing happens (operator is not monitoring) From: NANOG On Behalf Of Alan Hannan Sent: Thursday, September 20, 2018 7:12 PM To: Unknown Subject: overages for power usage What kind of typical overage costs have you seen when a customer/you use more than you've committed to? I'm especially interested in datacenter power situations, where maybe you sign up for 5kw or 500kw and use more than that in a given month. Is it billed at the same rate? Is it billed at a higher rate? What's the % increase of the higher rate versus the regular rate? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From cscora at apnic.net Fri Sep 21 18:03:02 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 22 Sep 2018 04:03:02 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180921180302.802AFC450F@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 22 Sep, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 717186 Prefixes after maximum aggregation (per Origin AS): 275396 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 344253 Total ASes present in the Internet Routing Table: 61918 Prefixes per ASN: 11.58 Origin-only ASes present in the Internet Routing Table: 53461 Origin ASes announcing only one prefix: 23313 Transit ASes present in the Internet Routing Table: 8457 Transit-only ASes present in the Internet Routing Table: 263 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 36 Max AS path prepend of ASN ( 30873) 34 Prefixes from unregistered ASNs in the Routing Table: 66 Number of instances of unregistered ASNs: 66 Number of 32-bit ASNs allocated by the RIRs: 24155 Number of 32-bit ASNs visible in the Routing Table: 19503 Prefixes from 32-bit ASNs in the Routing Table: 81974 Number of bogon 32-bit ASNs visible in the Routing Table: 27 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 312 Number of addresses announced to Internet: 2852765379 Equivalent to 170 /8s, 9 /16s and 190 /24s Percentage of available address space announced: 77.1 Percentage of allocated address space announced: 77.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.0 Total number of prefixes smaller than registry allocations: 239906 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 195142 Total APNIC prefixes after maximum aggregation: 55652 APNIC Deaggregation factor: 3.51 Prefixes being announced from the APNIC address blocks: 193036 Unique aggregates announced from the APNIC address blocks: 79550 APNIC Region origin ASes present in the Internet Routing Table: 9105 APNIC Prefixes per ASN: 21.20 APNIC Region origin ASes announcing only one prefix: 2568 APNIC Region transit ASes present in the Internet Routing Table: 1353 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4066 Number of APNIC addresses announced to Internet: 767534722 Equivalent to 45 /8s, 191 /16s and 166 /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: 213254 Total ARIN prefixes after maximum aggregation: 100728 ARIN Deaggregation factor: 2.12 Prefixes being announced from the ARIN address blocks: 212954 Unique aggregates announced from the ARIN address blocks: 101173 ARIN Region origin ASes present in the Internet Routing Table: 18240 ARIN Prefixes per ASN: 11.68 ARIN Region origin ASes announcing only one prefix: 6761 ARIN Region transit ASes present in the Internet Routing Table: 1810 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2433 Number of ARIN addresses announced to Internet: 1097175968 Equivalent to 65 /8s, 101 /16s and 147 /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: 196125 Total RIPE prefixes after maximum aggregation: 93529 RIPE Deaggregation factor: 2.10 Prefixes being announced from the RIPE address blocks: 192440 Unique aggregates announced from the RIPE address blocks: 113807 RIPE Region origin ASes present in the Internet Routing Table: 25510 RIPE Prefixes per ASN: 7.54 RIPE Region origin ASes announcing only one prefix: 11495 RIPE Region transit ASes present in the Internet Routing Table: 3518 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 36 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7420 Number of RIPE addresses announced to Internet: 714498432 Equivalent to 42 /8s, 150 /16s and 97 /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: 93003 Total LACNIC prefixes after maximum aggregation: 21234 LACNIC Deaggregation factor: 4.38 Prefixes being announced from the LACNIC address blocks: 94383 Unique aggregates announced from the LACNIC address blocks: 41228 LACNIC Region origin ASes present in the Internet Routing Table: 7575 LACNIC Prefixes per ASN: 12.46 LACNIC Region origin ASes announcing only one prefix: 2085 LACNIC Region transit ASes present in the Internet Routing Table: 1433 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5115 Number of LACNIC addresses announced to Internet: 172168992 Equivalent to 10 /8s, 67 /16s and 23 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 19595 Total AfriNIC prefixes after maximum aggregation: 4194 AfriNIC Deaggregation factor: 4.67 Prefixes being announced from the AfriNIC address blocks: 24061 Unique aggregates announced from the AfriNIC address blocks: 8230 AfriNIC Region origin ASes present in the Internet Routing Table: 1200 AfriNIC Prefixes per ASN: 20.05 AfriNIC Region origin ASes announcing only one prefix: 404 AfriNIC Region transit ASes present in the Internet Routing Table: 242 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 26 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 469 Number of AfriNIC addresses announced to Internet: 100942592 Equivalent to 6 /8s, 4 /16s and 67 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 4633 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4445 483 474 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 2996 1154 90 VIETEL-AS-AP Viettel Group, VN 4766 2823 11130 765 KIXS-AS-KR Korea Telecom, KR 9829 2811 1495 540 BSNL-NIB National Internet Backbone, IN 45899 2751 1666 157 VNPT-AS-VN VNPT Corp, VN 9394 2646 4907 31 CTTNET China TieTong Telecommunications 9808 2266 8699 26 CMNET-GD Guangdong Mobile Communication 17974 2247 956 76 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4755 2120 417 204 TATACOMM-AS TATA Communications formerl Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 11492 3580 241 447 CABLEONE - CABLE ONE, INC., US 6327 3469 1324 82 SHAW - Shaw Communications Inc., CA 22773 3238 2971 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2289 4938 794 AMAZON-02 - Amazon.com, Inc., US 18566 2163 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2157 2741 520 CHARTER-NET-HKY-NC - Charter Communicat 30036 2047 347 138 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 2044 5082 606 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16625 1998 1077 1505 AKAMAI-AS - Akamai Technologies, Inc., 5650 1887 3224 1320 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 4897 1614 126 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3061 378 51 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2579 606 1918 AKAMAI-ASN1, US 12389 2058 1943 698 ROSTELECOM-AS, RU 34984 2040 336 508 TELLCOM-AS, TR 9121 1905 1691 16 TTNET, TR 13188 1603 100 46 TRIOLAN, UA 8402 1266 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1241 355 21 UKRTELNET, UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5439 3320 604 Uninet S.A. de C.V., MX 10620 3225 493 777 Telmex Colombia S.A., CO 11830 2653 370 81 Instituto Costarricense de Electricidad 6503 1654 444 66 Axtel, S.A.B. de C.V., MX 7303 1431 954 205 Telecom Argentina S.A., AR 28573 1095 2231 196 CLARO S.A., BR 3816 1016 509 121 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 944 377 31 Telefonica del Peru S.A.A., PE 11172 933 128 70 Alestra, S. de R.L. de C.V., MX 18881 919 1114 28 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1196 396 48 LINKdotNET-AS, EG 37611 902 107 9 Afrihost, ZA 36903 778 391 137 MT-MPLS, MA 36992 749 1411 41 ETISALAT-MISR, EG 24835 658 818 18 RAYA-AS, EG 8452 604 1728 14 TE-AS TE-AS, EG 37492 473 470 55 ORANGE-, TN 29571 463 70 11 ORANGE-COTE-IVOIRE, CI 37342 386 32 1 MOVITEL, MZ 23889 376 231 15 MauritiusTelecom, MU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5439 3320 604 Uninet S.A. de C.V., MX 12479 4897 1614 126 UNI2-AS, ES 4538 4633 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4445 483 474 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 11492 3580 241 447 CABLEONE - CABLE ONE, INC., US 6327 3469 1324 82 SHAW - Shaw Communications Inc., CA 22773 3238 2971 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3225 493 777 Telmex Colombia S.A., CO 8551 3061 378 51 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 4897 4771 UNI2-AS, ES 4538 4633 4559 ERX-CERNET-BKB China Education and Research Net 7545 4445 3971 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3469 3387 SHAW - Shaw Communications Inc., CA 11492 3580 3133 CABLEONE - CABLE ONE, INC., US 22773 3238 3082 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3061 3010 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 2996 2906 VIETEL-AS-AP Viettel Group, VN 9394 2646 2615 CTTNET China TieTong Telecommunications Corpora 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 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 64121 UNALLOCATED 98.159.9.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64121 UNALLOCATED 98.159.12.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64140 UNALLOCATED 98.159.14.0/24 64121 UNKNOWN 65001 PRIVATE 109.161.56.0/24 13118 ASN-YARTELECOM PJSC Rostelecom 64643 PRIVATE 119.44.18.0/24 9394 CTTNET China TieTong Telecommu Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.136.0/24 37500 -Reserved AS-, ZZ 41.76.138.0/24 37500 -Reserved AS-, ZZ 41.76.139.0/24 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/24 37500 -Reserved AS-, ZZ 41.76.141.0/24 37500 -Reserved AS-, ZZ 41.76.142.0/24 37500 -Reserved AS-, ZZ 41.76.143.0/24 37500 -Reserved AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:14 /9:11 /10:36 /11:98 /12:289 /13:564 /14:1099 /15:1883 /16:13329 /17:7899 /18:13801 /19:25339 /20:39520 /21:45890 /22:89020 /23:72940 /24:403255 /25:821 /26:620 /27:627 /28:36 /29:21 /30:19 /31:4 /32:51 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 3649 4897 UNI2-AS, ES 6327 3256 3469 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2831 3580 CABLEONE - CABLE ONE, INC., US 8551 2517 3061 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2500 3238 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2057 2163 MEGAPATH5-US - MegaPath Corporation, US 11830 2003 2653 Instituto Costarricense de Electricidad y Telec 30036 1795 2047 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1554 1887 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:1597 2:846 4:18 5:2826 6:44 7:1 8:1115 12:1866 13:211 14:1811 15:34 16:3 17:196 18:55 20:50 23:2478 24:2413 25:2 27:2498 31:1982 32:88 35:29 36:534 37:2840 38:1531 39:261 40:112 41:3221 42:708 43:1920 44:117 45:5558 46:3116 47:215 49:1349 50:1058 51:318 52:1087 54:367 55:3 56:12 57:38 58:1613 59:986 60:417 61:2089 62:1901 63:1799 64:5041 65:2205 66:4747 67:2676 68:1151 69:3362 70:1158 71:576 72:2228 74:2724 75:416 76:458 77:1616 78:1732 79:2240 80:1568 81:1399 82:1061 83:791 84:1042 85:2026 86:563 87:1427 88:938 89:2341 90:211 91:6437 92:1280 93:2371 94:2432 95:3031 96:933 97:354 98:927 99:142 100:87 101:1197 102:210 103:18648 104:3524 105:218 106:761 107:1799 108:706 109:3328 110:1645 111:1806 112:1335 113:1306 114:1141 115:1677 116:1672 117:1784 118:2201 119:1668 120:1081 121:1056 122:2372 123:1639 124:1428 125:1930 128:1166 129:682 130:499 131:1612 132:724 133:191 134:1033 135:236 136:513 137:661 138:1927 139:685 140:536 141:751 142:844 143:1033 144:807 145:482 146:1242 147:733 148:1679 149:771 150:759 151:1101 152:845 153:323 154:1813 155:916 156:1465 157:808 158:659 159:1856 160:1445 161:828 162:2657 163:620 164:1094 165:1558 166:455 167:1214 168:3156 169:849 170:3982 171:492 172:1000 173:2087 174:997 175:802 176:2084 177:3984 178:2522 179:1294 180:2152 181:2426 182:2368 183:1269 184:1133 185:14124 186:3584 187:2520 188:2909 189:2030 190:8215 191:1412 192:9858 193:6256 194:5053 195:4001 196:2761 197:1610 198:5601 199:5964 200:7373 201:4973 202:10221 203:10279 204:4606 205:2890 206:3209 207:3195 208:3935 209:4106 210:3869 211:1999 212:3030 213:2811 214:1042 215:54 216:6030 217:2138 218:867 219:567 220:1812 221:999 222:994 223:1382 End of report From kaze0010 at umn.edu Fri Sep 21 17:25:54 2018 From: kaze0010 at umn.edu (Haudy Kazemi) Date: Fri, 21 Sep 2018 12:25:54 -0500 Subject: overages for power usage In-Reply-To: References: Message-ID: This isn't a data center specific answer but it may help explain upstream cost drivers that may factor into rates seen. For commercial and industrial customers, utilities will often measure and bill power demand in kW separate from energy in kWh. Energy may only be $0.04/kWh but demand charges can be tens of dollars per peak kW during a bill cycle (averaged over 15 minute intervals). The demand fees are a result of grid capacity requirements...the utilities need to maintain enough readily available generation capacity (turbines, storage, etc.) at all times to handle the peak loads, even if those loads are only seen once a year. If demand ever exceeds capacity, then brownouts and blackouts are on the plate. Assuming a $10/kW demand charge, a customer consuming 5000 kWh energy and drawing a 15 min peak average of 40 kW would pay $200 for energy + $400 for demand, for a monthly electric cost of $600. If the same customer could do load leveling to get those peaks down to 10 kW, they'd pay a $100 demand charge instead of $400, for a monthly electric cost of $300. With perfectly constant loads, 5000 kWh consumed over a 30 day month (720 hours) translates to 6.94 kW. 20 amp 240v circuits can each supply up to 3.84 kW continuous using the 80% loading rules. At 208v, that drops to 3.328 kW continuous. Said another way, with level loads, approximately 5000 kWh per month could be pulled through two 20 amp circuits running close to their capacity limits 24x7. Here is an example rate sheet for Xcel Energy in the US state of Colorado: https://www.xcelenergy.com/staticfiles/xe/Regulatory/COBusRates.pdf On Thu, Sep 20, 2018, 21:11 Alan Hannan wrote: > What kind of typical overage costs have you seen when a customer/you use > more than you've committed to? > > I'm especially interested in datacenter power situations, where maybe you > sign up for 5kw or 500kw and use more than that in a given month. Is it > billed at the same rate? Is it billed at a higher rate? What's the % > increase of the higher rate versus the regular rate? > > Thanks! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwoolleynanog at gmail.com Fri Sep 21 20:53:38 2018 From: rwoolleynanog at gmail.com (Ryan Woolley) Date: Fri, 21 Sep 2018 16:53:38 -0400 Subject: NANOG 74 agenda published Message-ID: NANOG Community, The NANOG 74 Agenda is published at http://www.cvent.com/d/qgqs03/16K and available as an iCal Feed. The Program Committee has worked closely with our speakers to develop a first-rate program and we encourage all attendees to enjoy the whole conference. As we review submitted content, minor changes to the agenda are possible and will be updated in the online feed. Thank you to the many members of our community who submitted interesting content for NANOG 74! Over 700 attendees have registered and the NANOG family looks forward to welcoming all of you to Vancouver. Useful Information: - NANOG 74 General Information and Registration: http://www.cvent.com/d/qgqs03 - NANOG 74 Agenda: http://www.cvent.com/d/qgqs03/16K - Hotel Room Block(s) Information: http://www.cvent.com/d/qgqs03/8K - Reminder, registration is required to participate in the NANOG 74 Hackathon: http://www.cvent.com/d/wgqhql A welcome message that will be sent to registered NANOG 74 attendees shortly will provide more information on scheduled events and applications to help you to make the most of your time in Vancouver. Safe travels and see you in Vancouver. Sincerely, Ryan Woolley NANOG PC From mark.tinka at seacom.mu Sat Sep 22 16:08:39 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 22 Sep 2018 18:08:39 +0200 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: <63F1BA1C-F91A-4227-905B-32D9250DB47D@awarecorp.co.za> References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> <8A48B84A-7284-43D4-826D-108F9E1EF71C@6by7.net> <3d5f160c-c06c-6b13-0588-e1ee2ddacb30@efes.iucc.ac.il> <1537258775.1572455.1511822440.6AE51233@webmail.messagingengine.com> <20180918155859.GA12055@sunf10.rd.bbc.co.uk> <63F1BA1C-F91A-4227-905B-32D9250DB47D@awarecorp.co.za> Message-ID: <99b23b93-a6f8-f06c-4d83-90650026df4a@seacom.mu> On 20/Sep/18 16:00, Andrew Ashley wrote: > > Agreed. This is a topic worthy of discussion all on its own! > Wonder how much of colo/DC operator space and revenue public cloud is eating in 2018? NAPAfrica employ a "free x-connect" model to peer at their exchange point provided you are a paying customer within their (Teraco) data centre in South Africa. Any x-connects you order that are not going to touch the exchange point are charged for (nowhere near the pricing you're typically seeing the U.S., I might add). They have gone one step further and offered free ports at their exchange point for their members. Again, provided you are a paying customer within their data centre. The model has been wildly successful, making it the largest data centre in Africa in a span of (if my memory is correct) a little under 3 years, far surpassing some that were there before. So, just an example of an element where a free-and-pay element has been reasonably successful without any rent-seeking behaviour. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Sat Sep 22 16:08:42 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 22 Sep 2018 18:08:42 +0200 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: References: <6797E6D9-D891-4BBE-B0B3-B8AABFABF4A2@hammerfiber.com> <61469105-FED5-4686-B7BE-2AD486FFDF65@delong.com> <8A48B84A-7284-43D4-826D-108F9E1EF71C@6by7.net> <3d5f160c-c06c-6b13-0588-e1ee2ddacb30@efes.iucc.ac.il> <08651119-3714-4A53-ADF0-989869253BE9@delong.com> <0D56BF2A-A5F2-4FC5-9E66-F8733AA2BADF@delong.com> Message-ID: On 20/Sep/18 03:13, Owen DeLong wrote: > > > At those prices, it doesn’t take a lot of XCs to justify the cost of > building an additional datacenter. These sorts of prices are generally visible either in cable landing stations, or data centres ran by submarine cable operators offering access to their cable system. A competing data centre in the same country will not provide cheaper access to one or a (limited) set of submarine cable systems that employ this stifling x-connect pricing model. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Mon Sep 24 05:35:29 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 24 Sep 2018 07:35:29 +0200 Subject: SAFNOG-4/EANOG/tzNOG: Live Stream The Conference Now! Message-ID: <5b19de40-9b18-8fe4-9a4e-5184d5d9c8ff@seacom.mu> Hello all. For those who would like to attend the meeting remotely, the live stream for the conference is now available on our web site:     http://www.safnog.org/ We look forward to you joining us online. Cheers, Mark Tinka On Behalf of the SAFNOG-4/EANOG/tzNOG Organizing Committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at 6by7.net Mon Sep 24 13:25:10 2018 From: ben at 6by7.net (Ben Cannon) Date: Mon, 24 Sep 2018 06:25:10 -0700 Subject: Poor Facebook CDN performance Message-ID: Can someone from FB reach out off list? I believe we have an ip geolocation or other issue with some routes causing occasional slow performance from the CDN for some users. Issue is intermittent and difficult to trace, but some photo comments are taking 5-10sec to load while home page data is near instant. -Ben From fastest963 at gmail.com Mon Sep 24 14:49:09 2018 From: fastest963 at gmail.com (James Hartig) Date: Mon, 24 Sep 2018 10:49:09 -0400 Subject: git fails over IPv6 with code.googlesource.com Message-ID: We've been having an issue pulling code from code.googlesource.com since last week over IPv6. If I disable IPv6 everything works fine. Same thing happens with go.googlesource.com. Example: git clone https://code.googlesource.com/google-api-go-client Cloning into 'google-api-go-client'... fatal: unable to access 'https://code.googlesource.com/google-api-go-client/': I/O operation timed out Can someone from Google reach out off-list? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Mon Sep 24 15:10:18 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 24 Sep 2018 11:10:18 -0400 Subject: git fails over IPv6 with code.googlesource.com In-Reply-To: References: Message-ID: On Mon, Sep 24, 2018 at 10:50 AM James Hartig wrote: > We've been having an issue pulling code from code.googlesource.com since > last week over IPv6. If I disable IPv6 > seems like someone forgot their v6 config... huh. > everything works fine. Same thing happens with go.googlesource.com. > Example: > > git clone https://code.googlesource.com/google-api-go-client > Cloning into 'google-api-go-client'... > fatal: unable to access ' > https://code.googlesource.com/google-api-go-client/': I/O operation timed > out > > Can someone from Google reach out off-list? Thanks! > someone may have already beat me to it, but I'll ask. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougm at nist.gov Mon Sep 24 15:30:35 2018 From: dougm at nist.gov (Montgomery, Douglas (Fed)) Date: Mon, 24 Sep 2018 15:30:35 +0000 Subject: [proj-bgp] adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor? In-Reply-To: References: <789C4684-5538-4613-BF37-F1FF810711CA@nist.gov> <17f419236905494fa2000696f23054f6@CRA110.am.necel.com> <72627D8D-8D71-49C7-B593-9E127FFFD5A4@nist.gov> Message-ID: Michel, The GoRTR services that cloudflare speaks of below might be an example of an organization positioned to offer the kind of services you suggest. https://blog.cloudflare.com/rpki-details/ dougm -- Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST On 9/18/18, 4:46 PM, "Michel Py" wrote: > Second, in general our mission is limited to supporting the development and promulgation of consensus standards and the development of test / measurement methods > and guidanceto accelerate their adoption. In particular we are not well positioned to provide operational Internet services of the nature you describe. You provide critical time services, this would be nothing compared to it. From morrowc.lists at gmail.com Mon Sep 24 15:31:05 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 24 Sep 2018 11:31:05 -0400 Subject: git fails over IPv6 with code.googlesource.com In-Reply-To: References: Message-ID: On Mon, Sep 24, 2018 at 11:10 AM Christopher Morrow wrote: > > > On Mon, Sep 24, 2018 at 10:50 AM James Hartig > wrote: > >> We've been having an issue pulling code from code.googlesource.com since >> last week over IPv6. If I disable IPv6 >> > > seems like someone forgot their v6 config... huh. > > >> everything works fine. Same thing happens with go.googlesource.com. >> Example: >> >> git clone https://code.googlesource.com/google-api-go-client >> Cloning into 'google-api-go-client'... >> fatal: unable to access ' >> https://code.googlesource.com/google-api-go-client/': I/O operation >> timed out >> >> Can someone from Google reach out off-list? Thanks! >> > > someone may have already beat me to it, but I'll ask. > ;; QUESTION SECTION: ;code.googlesource.com. IN AAAA ;; ANSWER SECTION: code.googlesource.com. 300 IN AAAA 2607:f8b0:400d:c0c::52 should be fixed... I think? $ telnet 2607:f8b0:400d:c0c::52 443 Trying 2607:f8b0:400d:c0c::52... Connected to 2607:f8b0:400d:c0c::52. Escape character is '^]'. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Sat Sep 22 01:09:22 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Sat, 22 Sep 2018 09:09:22 +0800 Subject: Subsea Cable Status Map Update - September 2018 In-Reply-To: References: Message-ID: Subsea Cable Status Map now aka Network Atlas is now in beta, and further details below. Visit https://beta.networkatlas.org to view our v0.1 Please feel free to add feature requests to below sheet. We are still looking for people who can provide high level kmz data. A quick reminder if you want to support coding/development of the underlying software, drop me a note privately. Thank you ---------- Forwarded message --------- From: Mehmet Akcin Date: Sat, Sep 22, 2018 at 6:51 AM Subject: Beta updates - Sept 22 To: Submarine Cable Map Status & Development Hello there, Our beta can be accessed here . Screenshot attached. [image: Screen Shot 2018-09-22 at 6.45.26 AM.png] now we are working on adding as many as cable systems possible to the map. If you are able to help with a system , please do let us know. We are going to be able to let registered users to update cable status very soon. Next week we hope to present this project in Submarine Networks World Conference and seek some support for development funding and network KMZ gathering efforts. in the mean time if you have feature suggestions you can enter them here . thank you and have a nice day. -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.dore at freethought-internet.co.uk Mon Sep 24 16:35:12 2018 From: edward.dore at freethought-internet.co.uk (Edward Dore) Date: Mon, 24 Sep 2018 16:35:12 +0000 Subject: Subsea Cable Status Map Update - September 2018 In-Reply-To: References: Message-ID: <47A8976A-CE08-4D65-8B9E-DEAFEBF5DF6C@freethought-internet.co.uk> Is that URL correct? https://beta.networkatlas.org/ isn’t working for me – I can’t establish a TLS connection: ~ edward$ openssl s_client -connect beta.networkatlas.org:443 -servername 443 CONNECTED(00000005) 140735891764168:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.50.2/libressl/ssl/s23_clnt.c:541: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 330 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated --- http://beta.networkatlas.org/ redirects me to http://server.michogarcia.org/ which does give me a map. Edward Dore Freethought Internet From: NANOG on behalf of Mehmet Akcin Date: Monday, 24 September 2018 at 17:25 To: nanog Subject: Subsea Cable Status Map Update - September 2018 Subsea Cable Status Map now aka Network Atlas is now in beta, and further details below. Visit https://beta.networkatlas.org to view our v0.1 Please feel free to add feature requests to below sheet. We are still looking for people who can provide high level kmz data. A quick reminder if you want to support coding/development of the underlying software, drop me a note privately. Thank you ---------- Forwarded message --------- From: Mehmet Akcin > Date: Sat, Sep 22, 2018 at 6:51 AM Subject: Beta updates - Sept 22 To: Submarine Cable Map Status & Development > Hello there, Our beta can be accessed here. Screenshot attached. [Screen Shot 2018-09-22 at 6.45.26 AM.png] now we are working on adding as many as cable systems possible to the map. If you are able to help with a system , please do let us know. We are going to be able to let registered users to update cable status very soon. Next week we hope to present this project in Submarine Networks World Conference and seek some support for development funding and network KMZ gathering efforts. in the mean time if you have feature suggestions you can enter them here. thank you and have a nice day. -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmith at ecsis.net Mon Sep 24 16:42:31 2018 From: lesmith at ecsis.net (Larry Smith) Date: Mon, 24 Sep 2018 11:42:31 -0500 Subject: Subsea Cable Status Map Update - September 2018 In-Reply-To: <47A8976A-CE08-4D65-8B9E-DEAFEBF5DF6C@freethought-internet.co.uk> References: <47A8976A-CE08-4D65-8B9E-DEAFEBF5DF6C@freethought-internet.co.uk> Message-ID: <201809241142.31591.lesmith@ecsis.net> It seems to work http and redirects to the original server.michogarcia.org link. -- Larry Smith lesmith at ecsis.net On Mon September 24 2018 11:35, Edward Dore wrote: > Is that URL correct? https://beta.networkatlas.org/ isn’t working for me – > I can’t establish a TLS connection: > > ~ edward$ openssl s_client -connect beta.networkatlas.org:443 -servername > 443 CONNECTED(00000005) > 140735891764168:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 > alert handshake > failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-2 >2.50.2/libressl/ssl/s23_clnt.c:541: --- > no peer certificate available > --- > No client certificate CA names sent > --- > SSL handshake has read 7 bytes and written 330 bytes > --- > New, (NONE), Cipher is (NONE) > Secure Renegotiation IS NOT supported > Compression: NONE > Expansion: NONE > No ALPN negotiated > --- > > http://beta.networkatlas.org/ redirects me to > http://server.michogarcia.org/ which does give me a map. > > Edward Dore > Freethought Internet > > From: NANOG on behalf of Mehmet Akcin > Date: Monday, 24 September 2018 at 17:25 > To: nanog > Subject: Subsea Cable Status Map Update - September 2018 > > Subsea Cable Status Map now aka Network Atlas is now in beta, and further > details below. Visit https://beta.networkatlas.org to view our v0.1 > > Please feel free to add feature requests to below sheet. > > We are still looking for people who can provide high level kmz data. > > A quick reminder if you want to support coding/development of the > underlying software, drop me a note privately. > > Thank you > > ---------- Forwarded message --------- > From: Mehmet Akcin > > Date: Sat, Sep 22, 2018 at 6:51 AM > Subject: Beta updates - Sept 22 > To: Submarine Cable Map Status & Development > > > > Hello there, > > Our beta can be accessed here. Screenshot > attached. > > [Screen Shot 2018-09-22 at 6.45.26 AM.png] > > now we are working on adding as many as cable systems possible to the map. > If you are able to help with a system , please do let us know. > > We are going to be able to let registered users to update cable status very > soon. Next week we hope to present this project in Submarine Networks World > Conference and seek some support for development funding and network KMZ > gathering efforts. > > in the mean time if you have feature suggestions you can enter them > here6CMz1gboRbAvc/edit#gid=253592441>. > > thank you and have a nice day. > -- > Mehmet > +1-424-298-1903 From alyssonjose at gmail.com Mon Sep 24 17:23:05 2018 From: alyssonjose at gmail.com (Alysson Jose Silva) Date: Mon, 24 Sep 2018 14:23:05 -0300 Subject: Subsea Cable Status Map Update - September 2018 In-Reply-To: <47A8976A-CE08-4D65-8B9E-DEAFEBF5DF6C@freethought-internet.co.uk> References: <47A8976A-CE08-4D65-8B9E-DEAFEBF5DF6C@freethought-internet.co.uk> Message-ID: <336dfef1-83a2-5a48-32b2-73630f499459@gmail.com> Hi all Not working for me either. Em 24/09/2018 13:35, Edward Dore escreveu: > > Is that URL correct? https://beta.networkatlas.org/ > isn’t working for me – I can’t > establish a TLS connection: > > ~ edward$ openssl s_client -connect beta.networkatlas.org:443 > -servername 443 > > CONNECTED(00000005) > > 140735891764168:error:14077410:SSL > routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake > failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.50.2/libressl/ssl/s23_clnt.c:541: > > --- > > no peer certificate available > > --- > > No client certificate CA names sent > > --- > > SSL handshake has read 7 bytes and written 330 bytes > > --- > > New, (NONE), Cipher is (NONE) > > Secure Renegotiation IS NOT supported > > Compression: NONE > > Expansion: NONE > > No ALPN negotiated > > --- > > http://beta.networkatlas.org/ redirects me to > http://server.michogarcia.org/ which does give me a map. > > Edward Dore > > Freethought Internet > > *From: *NANOG on behalf of Mehmet Akcin > > *Date: *Monday, 24 September 2018 at 17:25 > *To: *nanog > *Subject: *Subsea Cable Status Map Update - September 2018 > > Subsea Cable Status Map now aka Network Atlas is now in beta, and > further details below. Visit https://beta.networkatlas.org to view our > v0.1 > > Please feel free to add feature requests to below sheet. > > We are still looking for people who can provide high level kmz data. > > A quick reminder if you want to support coding/development of the > underlying software, drop me a note privately. > > Thank you > > ---------- Forwarded message --------- > From: *Mehmet Akcin* > > Date: Sat, Sep 22, 2018 at 6:51 AM > Subject: Beta updates - Sept 22 > To: Submarine Cable Map Status & Development > > > Hello there, > > Our beta can be accessed here . > Screenshot attached. > > Screen Shot 2018-09-22 at 6.45.26 AM.png > > now we are working on adding as many as cable systems possible to the > map. If you are able to help with a system , please do let us know. > > We are going to be able to let registered users to update cable status > very soon. Next week we hope to present this project in Submarine > Networks World Conference and seek some support for development > funding and network KMZ gathering efforts. > > in the mean time if you have feature suggestions you can enter them > here > . > > thank you and have a nice day. > > -- > > Mehmet > +1-424-298-1903 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Mon Sep 24 23:00:50 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 25 Sep 2018 07:00:50 +0800 Subject: Subsea Cable Status Map Update - September 2018 In-Reply-To: <336dfef1-83a2-5a48-32b2-73630f499459@gmail.com> References: <47A8976A-CE08-4D65-8B9E-DEAFEBF5DF6C@freethought-internet.co.uk> <336dfef1-83a2-5a48-32b2-73630f499459@gmail.com> Message-ID: Try to go to http://server.michogarcia.org// On Tue, Sep 25, 2018 at 5:35 AM Alysson Jose Silva wrote: > Hi all > > Not working for me either. > Em 24/09/2018 13:35, Edward Dore escreveu: > > Is that URL correct? https://beta.networkatlas.org/ isn’t working for me > – I can’t establish a TLS connection: > > > > ~ edward$ openssl s_client -connect beta.networkatlas.org:443 -servername > 443 > > CONNECTED(00000005) > > 140735891764168:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 > alert handshake > failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.50.2/libressl/ssl/s23_clnt.c:541: > > --- > > no peer certificate available > > --- > > No client certificate CA names sent > > --- > > SSL handshake has read 7 bytes and written 330 bytes > > --- > > New, (NONE), Cipher is (NONE) > > Secure Renegotiation IS NOT supported > > Compression: NONE > > Expansion: NONE > > No ALPN negotiated > > --- > > > > http://beta.networkatlas.org/ redirects me to > http://server.michogarcia.org/ which does give me a map. > > > > Edward Dore > > Freethought Internet > > > > *From: *NANOG on > behalf of Mehmet Akcin > *Date: *Monday, 24 September 2018 at 17:25 > *To: *nanog > *Subject: *Subsea Cable Status Map Update - September 2018 > > > > Subsea Cable Status Map now aka Network Atlas is now in beta, and further > details below. Visit https://beta.networkatlas.org to view our v0.1 > > > > Please feel free to add feature requests to below sheet. > > > > We are still looking for people who can provide high level kmz data. > > > > A quick reminder if you want to support coding/development of the > underlying software, drop me a note privately. > > > > Thank you > > > > ---------- Forwarded message --------- > From: *Mehmet Akcin* > Date: Sat, Sep 22, 2018 at 6:51 AM > Subject: Beta updates - Sept 22 > To: Submarine Cable Map Status & Development > > > > Hello there, > > > > Our beta can be accessed here . > Screenshot attached. > > > > [image: Screen Shot 2018-09-22 at 6.45.26 AM.png] > > > > now we are working on adding as many as cable systems possible to the map. > If you are able to help with a system , please do let us know. > > > > We are going to be able to let registered users to update cable status > very soon. Next week we hope to present this project in Submarine Networks > World Conference and seek some support for development funding and network > KMZ gathering efforts. > > > > in the mean time if you have feature suggestions you can enter them here > > . > > > > thank you and have a nice day. > > -- > > Mehmet > +1-424-298-1903 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Tue Sep 25 03:08:34 2018 From: sean at donelan.com (Sean Donelan) Date: Mon, 24 Sep 2018 23:08:34 -0400 (EDT) Subject: Post Hurricane Irma and Maria Mitigation Assessment Team Report Message-ID: Today, FEMA published its Mitigation Assessment Team Report on the Hurricanes Irma and Maria impact on buildings, critical faciltiies, solar panels and other construction issues. Recommendation USVI-1a: USVI should adopt the latest hazard-resistant building codes and standards on a regular update cycle. Recommendation USVI-8: DPNR should consider hiring additional code enforcement staff. Recommendation USVI-14b: Homeowners should consider protecting the glazed window and door systems on their existing homes. Recommendation USVI-19: Develop and support a wind retrofit programs across USVI. Recommendation USVI-34a: Add specific design criteria for ground-mounted PV solar arrays and connections to ASCE 7-22 and reference them in other select codes. FEMA P-2021 | Mitigation Assessment Team Report: Hurricanes Irma and Maria in the U.S. Virgin Islands https://www.fema.gov/media-library/assets/documents/170486 Building Performance Observations, Recommendations, and Technical Guidance. In response to a request for technical support from the Federal Emergency Management (FEMA) Joint Field Office in St. Croix, FEMA’s Federal Insurance and Mitigation Administration’s (FIMA) Building Science Branch deployed a Mitigation Assessment Team (MAT) composed of national and regional experts to affected areas in St. Thomas, St. John, and St. Croix, in October and November, 2017. The MAT was charged with evaluating damage from Hurricanes Irma and Maria, especially for buildings constructed or reconstructed after Hurricane Marilyn (1995), to identify both successful and unsuccessful mitigation techniques. This work involved: assessing the performance of residential, nonresidential, and critical facilities affected by the storms; evaluating the performance of photovoltaic (PV) facilities; investigating the effects of wind speed-up due to the islands’ topography on building performance; and meeting with residents and local officials to better understand what transpired during and after the storms. From mehmet at akcin.net Tue Sep 25 11:14:11 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 25 Sep 2018 19:14:11 +0800 Subject: Subsea Cable Status Map Update - September 2018 In-Reply-To: References: <47A8976A-CE08-4D65-8B9E-DEAFEBF5DF6C@freethought-internet.co.uk> <336dfef1-83a2-5a48-32b2-73630f499459@gmail.com> Message-ID: Apologies everyone for the error in the link earlier. We have been working around the clock to be ready for submarine cable map as we are in Singapore for Submarine Networks World conference presentation. Page is getting better each day. http://beta.networkatlas.org is live version you can see. (still beta version..) cheers [image: Screen Shot 2018-09-25 at 7.08.07 PM.png] On Tue, Sep 25, 2018 at 7:00 AM Mehmet Akcin wrote: > Try to go to http://server.michogarcia.org// > > On Tue, Sep 25, 2018 at 5:35 AM Alysson Jose Silva > wrote: > >> Hi all >> >> Not working for me either. >> Em 24/09/2018 13:35, Edward Dore escreveu: >> >> Is that URL correct? https://beta.networkatlas.org/ isn’t working for me >> – I can’t establish a TLS connection: >> >> >> >> ~ edward$ openssl s_client -connect beta.networkatlas.org:443 >> -servername 443 >> >> CONNECTED(00000005) >> >> 140735891764168:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 >> alert handshake >> failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.50.2/libressl/ssl/s23_clnt.c:541: >> >> --- >> >> no peer certificate available >> >> --- >> >> No client certificate CA names sent >> >> --- >> >> SSL handshake has read 7 bytes and written 330 bytes >> >> --- >> >> New, (NONE), Cipher is (NONE) >> >> Secure Renegotiation IS NOT supported >> >> Compression: NONE >> >> Expansion: NONE >> >> No ALPN negotiated >> >> --- >> >> >> >> http://beta.networkatlas.org/ redirects me to >> http://server.michogarcia.org/ which does give me a map. >> >> >> >> Edward Dore >> >> Freethought Internet >> >> >> >> *From: *NANOG on >> behalf of Mehmet Akcin >> *Date: *Monday, 24 September 2018 at 17:25 >> *To: *nanog >> *Subject: *Subsea Cable Status Map Update - September 2018 >> >> >> >> Subsea Cable Status Map now aka Network Atlas is now in beta, and further >> details below. Visit https://beta.networkatlas.org to view our v0.1 >> >> >> >> Please feel free to add feature requests to below sheet. >> >> >> >> We are still looking for people who can provide high level kmz data. >> >> >> >> A quick reminder if you want to support coding/development of the >> underlying software, drop me a note privately. >> >> >> >> Thank you >> >> >> >> ---------- Forwarded message --------- >> From: *Mehmet Akcin* >> Date: Sat, Sep 22, 2018 at 6:51 AM >> Subject: Beta updates - Sept 22 >> To: Submarine Cable Map Status & Development >> >> >> >> Hello there, >> >> >> >> Our beta can be accessed here . >> Screenshot attached. >> >> >> >> [image: Screen Shot 2018-09-22 at 6.45.26 AM.png] >> >> >> >> now we are working on adding as many as cable systems possible to the >> map. If you are able to help with a system , please do let us know. >> >> >> >> We are going to be able to let registered users to update cable status >> very soon. Next week we hope to present this project in Submarine Networks >> World Conference and seek some support for development funding and network >> KMZ gathering efforts. >> >> >> >> in the mean time if you have feature suggestions you can enter them here >> >> . >> >> >> >> thank you and have a nice day. >> >> -- >> >> Mehmet >> +1-424-298-1903 >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidbass570 at gmail.com Tue Sep 25 16:13:05 2018 From: davidbass570 at gmail.com (David Bass) Date: Tue, 25 Sep 2018 11:13:05 -0500 Subject: O365 IP space Message-ID: Does anyone have a good list of all of the US IPs used for O365? Not looking for specific IPs, and can just use the blocks. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From edugas at unknowndevice.ca Tue Sep 25 16:16:02 2018 From: edugas at unknowndevice.ca (Eric Dugas) Date: Tue, 25 Sep 2018 12:16:02 -0400 Subject: O365 IP space In-Reply-To: References: Message-ID: <1537892145.local-fdb3b949-0cb0-v1.4.2-f587b7b7@getmailspring.com> First result on Google: https://docs.microsoft.com/en-ca/office365/enterprise/urls-and-ip-address-ranges?redirectSourcePath=%252farticle%252fOffice-365-URLs-and-IP-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2 On Sep 25 2018, at 12:13 pm, David Bass wrote: > > Does anyone have a good list of all of the US IPs used for O365? Not looking for specific IPs, and can just use the blocks. > > Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From smeuse at mara.org Tue Sep 25 16:18:50 2018 From: smeuse at mara.org (Steve Meuse) Date: Tue, 25 Sep 2018 12:18:50 -0400 Subject: O365 IP space In-Reply-To: References: Message-ID: https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges On Tue, Sep 25, 2018 at 12:13 PM David Bass wrote: > Does anyone have a good list of all of the US IPs used for O365? Not > looking for specific IPs, and can just use the blocks. > > Thanks! > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Tue Sep 25 16:26:48 2018 From: job at ntt.net (Job Snijders) Date: Tue, 25 Sep 2018 16:26:48 +0000 Subject: O365 IP space In-Reply-To: References: Message-ID: <20180925162648.GJ77517@vurt.meerval.net> On Tue, Sep 25, 2018 at 12:18:50PM -0400, Steve Meuse wrote: > https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges I think it is cool that companies take the time and effort to publish such useful lists. Keep it up! Kind regards, Job From davidbass570 at gmail.com Tue Sep 25 16:35:33 2018 From: davidbass570 at gmail.com (David Bass) Date: Tue, 25 Sep 2018 11:35:33 -0500 Subject: O365 IP space In-Reply-To: <20180925162648.GJ77517@vurt.meerval.net> References: <20180925162648.GJ77517@vurt.meerval.net> Message-ID: Sorry, I should have stated that I have already searched, and have seen the above mentioned docs as well as everything else on the first page of the search results. I guess what I was looking for was to see if somebody has already consolidated that list in to something easier to work with. On Tue, Sep 25, 2018 at 11:26 AM Job Snijders wrote: > On Tue, Sep 25, 2018 at 12:18:50PM -0400, Steve Meuse wrote: > > > https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges > > I think it is cool that companies take the time and effort to publish > such useful lists. Keep it up! > > Kind regards, > > Job > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ml at kenweb.org Tue Sep 25 17:13:03 2018 From: ml at kenweb.org (ML) Date: Tue, 25 Sep 2018 13:13:03 -0400 Subject: O365 IP space In-Reply-To: References: <20180925162648.GJ77517@vurt.meerval.net> Message-ID: <7302fceb-1e76-de1f-8823-f1eb0257ef76@kenweb.org> In the past I've pulled down an XML file that included the IP space for all of the O365 products.  Then I filtered, sorted and aggregated what I wanted for my internal use via a script. On 9/25/2018 12:35 PM, David Bass wrote: > Sorry, I should have stated that I have already searched, and have > seen the above mentioned docs as well as everything else on the first > page of the search results. > > I guess what I was looking for was to see if somebody has already > consolidated that list in to something easier to work with. > > On Tue, Sep 25, 2018 at 11:26 AM Job Snijders > wrote: > > On Tue, Sep 25, 2018 at 12:18:50PM -0400, Steve Meuse wrote: > > > https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges > > I think it is cool that companies take the time and effort to publish > such useful lists. Keep it up! > > Kind regards, > > Job > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matlockken at gmail.com Tue Sep 25 17:19:40 2018 From: matlockken at gmail.com (Ken Matlock) Date: Tue, 25 Sep 2018 11:19:40 -0600 Subject: O365 IP space In-Reply-To: <7302fceb-1e76-de1f-8823-f1eb0257ef76@kenweb.org> References: <20180925162648.GJ77517@vurt.meerval.net> <7302fceb-1e76-de1f-8823-f1eb0257ef76@kenweb.org> Message-ID: This list? https://support.content.office.net/en-us/static/O365IPAddresses.xml >From the linked-above page (it's somewhat obscured). Ken On Tue, Sep 25, 2018 at 11:14 AM ML wrote: > In the past I've pulled down an XML file that included the IP space for > all of the O365 products. Then I filtered, sorted and aggregated what I > wanted for my internal use via a script. > > On 9/25/2018 12:35 PM, David Bass wrote: > > Sorry, I should have stated that I have already searched, and have seen > the above mentioned docs as well as everything else on the first page of > the search results. > > I guess what I was looking for was to see if somebody has already > consolidated that list in to something easier to work with. > > On Tue, Sep 25, 2018 at 11:26 AM Job Snijders wrote: > >> On Tue, Sep 25, 2018 at 12:18:50PM -0400, Steve Meuse wrote: >> > >> https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges >> >> I think it is cool that companies take the time and effort to publish >> such useful lists. Keep it up! >> >> Kind regards, >> >> Job >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Tue Sep 25 17:30:05 2018 From: job at ntt.net (Job Snijders) Date: Tue, 25 Sep 2018 17:30:05 +0000 Subject: ARIN RPKI TAL deployment issues Message-ID: <20180925173005.GL77517@vurt.meerval.net> Dear NANOG, I'd like to draw attention to a very concerning development: it appears that the ARIN TAL is not as widely deployed as other RPKI TALs (such as RIPE or APNIC's TAL). This means that ARIN members are needlessly put at higher risk. Ben Cartwright-Cox performed RPKI research a few weeks ago where he compared the (un)reachability of RPKI Invalid announcements using ARIN, RPKI, APNIC and JPNIC space. The full write-up is available here: https://blog.benjojo.co.uk/post/are-bgps-security-features-working-yet-rpki I quote Ben's assessment: """Using the data, we can also see that the providers that have not downloaded the ARIN TAL. Either because they were not aware that they needed to, or could not agree to the agreement they have with it. This is frustrating to watch. Since it means that ROA signing ARIN prefixes will be less secure than ROA signing others, until these restrictions are abolished. Even after that it will have a long term knock on effect as software updates take a long time to propagate to end networks.""" In other words, when creating RPKI ROAs for your resources, ARIN members are getting *LESS* in return compared to say RIPE members. As ARIN member I'd hope and expect the ARIN organisation to go above and beyond to distribute their RPKI TAL as widely as possible. (Think: proactively submitting the ARIN TAL to relevant open source projects, making the TAL available for download without restrictions or limitations). At the NANOG 74 meeting David Whisnick will talk about legal barriers to RPKI adoption and he'll offer suggestions for reform. I think Ben's observation that the ARIN TAL is less widely deployed is a direct result from the legal barriers that David identified. https://pc.nanog.org/static/published/meetings//NANOG74/daily/day_2.html#talk_1767 I fear that if no action is taken (e.g. when none of the RPKI Cache Validators can include the ARIN TAL in their software distribution [1]), we'll continue to see the gap between ARIN and the other RIRs widen. Software developers have indicated that the RPA is problematic and prevents BGP implementations from shipping "secure by default" software: https://lists.arin.net/pipermail/arin-consult/2018-April/001087.html When ARIN members create ROAs, I assume those members would also like networks *outside* the ARIN region to honor those ROAs and help prevent propagation of incorrect BGP announcements. The ARIN member and the operator of the foreign network may not even have any languages in common! I fear that limited deployment of the ARIN TAL is detrimental to the business interests of resource holders in the ARIN region. Kind regards, Job [1]: https://github.com/NLnetLabs/routinator/commit/b1e70746bb3768554fa439c5ced4e8b8484eeb00 From kushal.r at h4g.co Tue Sep 25 17:50:58 2018 From: kushal.r at h4g.co (Kushal) Date: Tue, 25 Sep 2018 23:20:58 +0530 Subject: Spirit/PalMettoNet Contact Message-ID: Does anyone have a contact over at Spirit Communications and/or PalmettoNet?  I’ve been trying to reach someone there to gather some information about their Transport and Transit services and have emailed and called all the contacts listed here - https://www.spiritcom.com/partner/carrier?t=meet-the-team with no success. Any help is appreciated. -- Kushal R Chief Executive | Host4Geeks site: host4geeks.com email: kushal.r at h4g.co skype: kush.raha -------------- next part -------------- An HTML attachment was scrubbed... URL: From glennabraas at gmail.com Tue Sep 25 16:51:17 2018 From: glennabraas at gmail.com (Glenn Abraas) Date: Tue, 25 Sep 2018 18:51:17 +0200 Subject: O365 IP space In-Reply-To: References: <20180925162648.GJ77517@vurt.meerval.net> Message-ID: <5EFB9BB2-4487-4F87-9E61-1CF86C1CF53B@gmail.com> They've got a tool somewhere that builds the entire list from a Powershell script. Search for proxy office365 tool. Sent from my iPhone > On 25 Sep 2018, at 18:35, David Bass wrote: > > Sorry, I should have stated that I have already searched, and have seen the above mentioned docs as well as everything else on the first page of the search results. > > I guess what I was looking for was to see if somebody has already consolidated that list in to something easier to work with. > >> On Tue, Sep 25, 2018 at 11:26 AM Job Snijders wrote: >> On Tue, Sep 25, 2018 at 12:18:50PM -0400, Steve Meuse wrote: >> > https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges >> >> I think it is cool that companies take the time and effort to publish >> such useful lists. Keep it up! >> >> Kind regards, >> >> Job -------------- next part -------------- An HTML attachment was scrubbed... URL: From rchien at verisk3e.com Tue Sep 25 17:24:33 2018 From: rchien at verisk3e.com (Chien, Ryan) Date: Tue, 25 Sep 2018 17:24:33 +0000 Subject: O365 IP space In-Reply-To: References: <20180925162648.GJ77517@vurt.meerval.net> <7302fceb-1e76-de1f-8823-f1eb0257ef76@kenweb.org> Message-ID: The IPs have changed a few times since the document’s inception, so I cross referenced the documented O365 IPs with ARIN’s database. I then chose to implement the CIDR as defined by ARIN (YMMV). https://whois.arin.net/rest/org/MSFT/nets https://whois.arin.net/rest/org/MSFT-Z/nets ________________________________ Ryan From: NANOG On Behalf Of Ken Matlock Sent: Tuesday, September 25, 2018 10:20 AM To: ml at kenweb.org Cc: NANOG Subject: Re: O365 IP space This list? https://support.content.office.net/en-us/static/O365IPAddresses.xml From the linked-above page (it's somewhat obscured). Ken On Tue, Sep 25, 2018 at 11:14 AM ML > wrote: In the past I've pulled down an XML file that included the IP space for all of the O365 products. Then I filtered, sorted and aggregated what I wanted for my internal use via a script. On 9/25/2018 12:35 PM, David Bass wrote: Sorry, I should have stated that I have already searched, and have seen the above mentioned docs as well as everything else on the first page of the search results. I guess what I was looking for was to see if somebody has already consolidated that list in to something easier to work with. On Tue, Sep 25, 2018 at 11:26 AM Job Snijders > wrote: On Tue, Sep 25, 2018 at 12:18:50PM -0400, Steve Meuse wrote: > https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges I think it is cool that companies take the time and effort to publish such useful lists. Keep it up! Kind regards, Job ________________________________ This email is intended solely for the recipient. It may contain privileged, proprietary or confidential information or material. If you are not the intended recipient, please delete this email and any attachments and notify the sender of the error. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at istaff.org Tue Sep 25 19:07:54 2018 From: jcurran at istaff.org (John Curran) Date: Tue, 25 Sep 2018 15:07:54 -0400 Subject: ARIN RPKI TAL deployment issues In-Reply-To: <20180925173005.GL77517@vurt.meerval.net> References: <20180925173005.GL77517@vurt.meerval.net> Message-ID: <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> On Sep 25, 2018, at 1:30 PM, Job Snijders wrote: > > """Using the data, we can also see that the providers that have not > downloaded the ARIN TAL. Either because they were not aware that > they needed to, or could not agree to the agreement they have with > it. Job - Is it possible to ascertain how many of those who have not downloaded the ARIN TAL are also publishing ROA’s via RIPE’s CA? /John From job at ntt.net Tue Sep 25 19:34:51 2018 From: job at ntt.net (Job Snijders) Date: Tue, 25 Sep 2018 19:34:51 +0000 Subject: ARIN RPKI TAL deployment issues In-Reply-To: <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> Message-ID: <20180925193451.GM77517@vurt.meerval.net> On Tue, Sep 25, 2018 at 03:07:54PM -0400, John Curran wrote: > On Sep 25, 2018, at 1:30 PM, Job Snijders wrote: > > > > """Using the data, we can also see that the providers that have not > > downloaded the ARIN TAL. Either because they were not aware that > > they needed to, or could not agree to the agreement they have with > > it. > > Is it possible to ascertain how many of those who have not downloaded > the ARIN TAL are also publishing ROA’s via RIPE’s CA? I'm sure we could extend the data set to figure this out. But given the assymmetric relation between applying Origin Validation based on RPKI data and publishing ROAs, the number will be between 0% and 100% and over time may go up or down. So, out of curiosity, what is your underlaying question? (An example: a route server operator generally doesn't originate any BGP announcements themselves, but route servers are in an ideal position to perform RPKI based BGP Origin Validation.) What I'm hoping for is that there is a way for the ARIN TAL to be included in software distributions, without compromising ARIN's legal position. Perhaps an exception for software distributors would already go a long way? "You can include the ARIN TAL in your software distribution as long as you also include an unmodified copy of the https://www.arin.net/resources/rpki/rpa.pdf file alongside it." Kind regards, Job From michel.py at tsisemi.com Tue Sep 25 20:13:30 2018 From: michel.py at tsisemi.com (Michel Py) Date: Tue, 25 Sep 2018 20:13:30 +0000 Subject: ARIN RPKI TAL deployment issues In-Reply-To: <20180925193451.GM77517@vurt.meerval.net> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> Message-ID: > Job Snijders wrote : > (An example: a route server operator generally doesn't originate any BGP announcements themselves, > but route servers are in an ideal position to perform RPKI based BGP Origin Validation.) Indeed. Also, an IX should have an RPKI validator accessible by its members, and the RPA makes that impossible. IMHO, the RPA is too restrictive. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From ttauber at 1-4-5.net Tue Sep 25 20:14:11 2018 From: ttauber at 1-4-5.net (Tony Tauber) Date: Tue, 25 Sep 2018 16:14:11 -0400 Subject: ARIN RPKI TAL deployment issues In-Reply-To: <20180925193451.GM77517@vurt.meerval.net> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> Message-ID: Sounds reasonable to me but IANAL, nor an RIR, nor an IXP. IXPs however do seem to be the sites of some number of recent mis-originations (putting it as charitably as possible). Let's try and make it harder for bad actors to do their mischief. Thanks, Tony On Tue, Sep 25, 2018 at 3:36 PM Job Snijders wrote: > On Tue, Sep 25, 2018 at 03:07:54PM -0400, John Curran wrote: > > On Sep 25, 2018, at 1:30 PM, Job Snijders wrote: > > > > > > """Using the data, we can also see that the providers that have not > > > downloaded the ARIN TAL. Either because they were not aware that > > > they needed to, or could not agree to the agreement they have with > > > it. > > > > Is it possible to ascertain how many of those who have not downloaded > > the ARIN TAL are also publishing ROA’s via RIPE’s CA? > > I'm sure we could extend the data set to figure this out. But given the > assymmetric relation between applying Origin Validation based on RPKI > data and publishing ROAs, the number will be between 0% and 100% and > over time may go up or down. So, out of curiosity, what is your > underlaying question? > > (An example: a route server operator generally doesn't originate any BGP > announcements themselves, but route servers are in an ideal position to > perform RPKI based BGP Origin Validation.) > > What I'm hoping for is that there is a way for the ARIN TAL to be > included in software distributions, without compromising ARIN's legal > position. > > Perhaps an exception for software distributors would already go a long > way? > > "You can include the ARIN TAL in your software distribution as long > as you also include an unmodified copy of the > https://www.arin.net/resources/rpki/rpa.pdf file alongside it." > > Kind regards, > > Job > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at thousandeyes.com Tue Sep 25 18:40:43 2018 From: nick at thousandeyes.com (Nick Kephart) Date: Tue, 25 Sep 2018 11:40:43 -0700 Subject: O365 IP space In-Reply-To: References: <20180925162648.GJ77517@vurt.meerval.net> <7302fceb-1e76-de1f-8823-f1eb0257ef76@kenweb.org> Message-ID: Microsoft also now publishes this data as a JSON and RSS and change log available from https://techcommunity.microsoft.com/t5/Office-365-Blog/Announcing-Office-365-endpoint-categories-and-Office-365-IP/ba-p/177638 On Tue, Sep 25, 2018 at 10:24 AM, Chien, Ryan wrote: > The IPs have changed a few times since the document’s inception, so I > cross referenced the documented O365 IPs with ARIN’s database. I then > chose to implement the CIDR as defined by ARIN (YMMV). > > > > https://whois.arin.net/rest/org/MSFT/nets > > https://whois.arin.net/rest/org/MSFT-Z/nets > > > ------------------------------ > > *Ryan* > > > > *From:* NANOG *On Behalf Of *Ken Matlock > *Sent:* Tuesday, September 25, 2018 10:20 AM > *To:* ml at kenweb.org > *Cc:* NANOG > *Subject:* Re: O365 IP space > > > > This list? > > > > https://support.content.office.net/en-us/static/O365IPAddresses.xml > > > > > From the linked-above page (it's somewhat obscured). > > > > Ken > > > > > > On Tue, Sep 25, 2018 at 11:14 AM ML wrote: > > In the past I've pulled down an XML file that included the IP space for > all of the O365 products. Then I filtered, sorted and aggregated what I > wanted for my internal use via a script. > > > > On 9/25/2018 12:35 PM, David Bass wrote: > > Sorry, I should have stated that I have already searched, and have seen > the above mentioned docs as well as everything else on the first page of > the search results. > > > > I guess what I was looking for was to see if somebody has already > consolidated that list in to something easier to work with. > > > > On Tue, Sep 25, 2018 at 11:26 AM Job Snijders wrote: > > On Tue, Sep 25, 2018 at 12:18:50PM -0400, Steve Meuse wrote: > > https://docs.microsoft.com/en-us/office365/enterprise/urls- > and-ip-address-ranges > > > I think it is cool that companies take the time and effort to publish > such useful lists. Keep it up! > > Kind regards, > > Job > > > > > ------------------------------ > > This email is intended solely for the recipient. It may contain > privileged, proprietary or confidential information or material. If you are > not the intended recipient, please delete this email and any attachments > and notify the sender of the error. > -- Nick Kephart ThousandEyes Sr. Director of Product Management m: 415-728-7415 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Tue Sep 25 20:28:54 2018 From: jcurran at arin.net (John Curran) Date: Tue, 25 Sep 2018 20:28:54 +0000 Subject: ARIN RPKI TAL deployment issues In-Reply-To: <20180925193451.GM77517@vurt.meerval.net> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> Message-ID: <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> On 25 Sep 2018, at 3:34 PM, Job Snijders wrote: > > On Tue, Sep 25, 2018 at 03:07:54PM -0400, John Curran wrote: >> On Sep 25, 2018, at 1:30 PM, Job Snijders wrote: >>> >>> """Using the data, we can also see that the providers that have not >>> downloaded the ARIN TAL. Either because they were not aware that >>> they needed to, or could not agree to the agreement they have with >>> it. >> >> Is it possible to ascertain how many of those who have not downloaded >> the ARIN TAL are also publishing ROA’s via RIPE’s CA? > > I'm sure we could extend the data set to figure this out. It would be informative to know how many organizations potentially have concerns about the indemnification clause in the RPA but already agree to indemnification via RIPE NCC Certification Service Terms and Conditions. Thanks! /John John Curran President and CEO ARIN From jcurran at arin.net Tue Sep 25 20:33:47 2018 From: jcurran at arin.net (John Curran) Date: Tue, 25 Sep 2018 20:33:47 +0000 Subject: NANOG 74 Attendee participation in the 2018 NRO NC elections Message-ID: NANOGers - ARIN 42 and NANOG 74 attendees who are not ARIN Member Voting Contacts will be eligible to vote online from 1 October 2018 to 12 October 2018 in the Number Resource Organization Number Council (NRO NC) election for the ARIN region, if they are registered for the meetings by Thursday 27 September 2018. (If you are also an ARIN eligible Voting Contact, please note that you will vote in this same election beginning Thursday, 4 October when voting opens for the ARIN Board of Trustees and ARIN Advisory Council Elections.) The 2018 NRO NC candidates for the one open seat are: *Michael Arbrouet (No Affilaition) *Louie Lee, Goodle Fiber To view NRO NC candidate biographies and questionnaire responses, please visit: https://www.arin.net/participate/elections/candidate_bios.pdf Candidate Statements of Support may be viewed and made at: https://www.bigpulse.com/p51139/ To learn more about the NRO NC election procedures and the role of the NRO NC, please visit: https://www.arin.net/participate/elections/nronumbercouncil.html Note that all eligible ARIN 42 and NANOG 74 registered attendees will receive an email at 10:00 AM ET on Monday 1 October 2018 with instructions on how to cast your NRO NC ballot. The election closes at 6:00 PM EDT Friday 12 October 2018 and results will be announced the following week. Please visit the ARIN Elections Helpdesk that will be onsite in Vancouver, British Columbia if you have issues voting, or contact a representative of our Member Services team via email at > Thank you for participating! /John John Curran President and CEO American Registry for Internet Numbers (ARIN) -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Tue Sep 25 21:04:26 2018 From: job at ntt.net (Job Snijders) Date: Tue, 25 Sep 2018 21:04:26 +0000 Subject: ARIN RPKI TAL deployment issues In-Reply-To: <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> Message-ID: <20180925210426.GO77517@vurt.meerval.net> Dear John, On Tue, Sep 25, 2018 at 08:28:54PM +0000, John Curran wrote: > On 25 Sep 2018, at 3:34 PM, Job Snijders wrote: > > > > On Tue, Sep 25, 2018 at 03:07:54PM -0400, John Curran wrote: > >> On Sep 25, 2018, at 1:30 PM, Job Snijders wrote: > >>> > >>> """Using the data, we can also see that the providers that have not > >>> downloaded the ARIN TAL. Either because they were not aware that > >>> they needed to, or could not agree to the agreement they have with > >>> it. > >> > >> Is it possible to ascertain how many of those who have not downloaded > >> the ARIN TAL are also publishing ROA’s via RIPE’s CA? > > > > I'm sure we could extend the data set to figure this out. > > It would be informative to know how many organizations potentially > have concerns about the indemnification clause in the RPA but already > agree to indemnification via RIPE NCC Certification Service Terms and > Conditions. This seems a matter of personal curiosity that perhaps distracts from the problem at hand: the ARIN TAL is less widely deployed than the other TALs. I'm open to solutions or suggestions to get the ARIN TAL more widely distributed, however I do think that inclusion in the RPKI Cache Validators is a *key* element, so the ARIN TAL can be used after a default installation of such software. We really need to bring it back down to "apt install rpki-cache-validator" to best serve the interests of the ARIN members. Imagine the Chrome browser shipping without any of the TLS Root Certificates, or Unbound without the DNSSEC root key! Kind regards, Job From jcurran at arin.net Tue Sep 25 21:17:56 2018 From: jcurran at arin.net (John Curran) Date: Tue, 25 Sep 2018 21:17:56 +0000 Subject: ARIN RPKI TAL deployment issues In-Reply-To: <20180925210426.GO77517@vurt.meerval.net> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <20180925210426.GO77517@vurt.meerval.net> Message-ID: On 25 Sep 2018, at 5:04 PM, Job Snijders wrote: > >> It would be informative to know how many organizations potentially >> have concerns about the indemnification clause in the RPA but already >> agree to indemnification via RIPE NCC Certification Service Terms and >> Conditions. > > This seems a matter of personal curiosity that perhaps distracts from > the problem at hand: the ARIN TAL is less widely deployed than the other > TALs. Job - I would have to disagree regarding whether question of indemnification is a simply a distraction… It has been raised by the operator community multiple times, and in fact, you indirectly reference the same issue by quoting a sentence in the write-up within your post - >> I quote Ben's assessment: >> >> """Using the data, we can also see that the providers that have not >> downloaded the ARIN TAL. Either because they were not aware that >> they needed to, or could not agree to the agreement they have with >> it.”" I believe that you correctly characterize the situation; i.e: 1) Either they were not aware they needed it (note this is trivial to fix with outreach/education and requires skills well within the range of anyone who is going to be doing routing validation based on RPKI data), or 2) They could not agree to ARIN RPA agreement (for which the most cited reason is the indemnification clause, but perplexing given agreement to other indemnification clauses such as RIPE’s Certification services.) Further analysis and characterization of those not using the ARIN TAL would help enormously in understanding which of the scenarios above is dominant, and prioritize efforts for addressing the situation. Thanks! /John John Curran President and CEO ARIN From job at ntt.net Tue Sep 25 21:51:03 2018 From: job at ntt.net (Job Snijders) Date: Tue, 25 Sep 2018 21:51:03 +0000 Subject: ARIN RPKI TAL deployment issues In-Reply-To: References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <20180925210426.GO77517@vurt.meerval.net> Message-ID: <20180925215103.GP77517@vurt.meerval.net> On Tue, Sep 25, 2018 at 09:17:56PM +0000, John Curran wrote: > On 25 Sep 2018, at 5:04 PM, Job Snijders wrote: > >> It would be informative to know how many organizations potentially > >> have concerns about the indemnification clause in the RPA but > >> already agree to indemnification via RIPE NCC Certification Service > >> Terms and Conditions. > > > > This seems a matter of personal curiosity that perhaps distracts > > from the problem at hand: the ARIN TAL is less widely deployed than > > the other TALs. > > I would have to disagree regarding whether question of indemnification > is a simply a distraction… It has been raised by the operator > community multiple times, and in fact, you indirectly reference the > same issue by quoting a sentence in the write-up within your post - > > >> I quote Ben's assessment: > >> > >> """Using the data, we can also see that the providers that have not > >> downloaded the ARIN TAL. Either because they were not aware that > >> they needed to, or could not agree to the agreement they have with > >> it.”" > > I believe that you correctly characterize the situation; i.e: > > 1) Either they were not aware they needed it (note this is trivial to > fix with outreach/education and requires skills well within the range > of anyone who is going to be doing routing validation based on RPKI > data), or My assessment (based on the data Ben collected) is that the current outreach & education are failing to accomplish the goal of widely distributing the ARIN TAL, and I fear this may get worse over time. > 2) They could not agree to ARIN RPA agreement (for which the most > cited reason is the indemnification clause, but perplexing given > agreement to other indemnification clauses such as RIPE’s > Certification services.) It may make sense to associate an implicit agreement (or perhaps a license?) with the ARIN TAL to limit risks to the ARIN organisation. "Use at your own risk"-style clauses are common and acceptable. In section 5 ("prohibited conduct") of the RPA I read: "You shall not, directly or indirectly, disclose, share, divulge, link to, rebroadcast, provide access to or in any other way make available the TAL to any third party, except as permitted by the ORCP Service Terms." I believe this prevents OpenBSD, Cisco, Juniper, etc... from shipping their operating system with a copy of the ARIN TAL, and as far as I understand is the reason that RIPE NCC's RPKI Cache Validator and the NLNetLabs RPKI Validator don't include the ARIN TAL either. > Further analysis and characterization of those not using the ARIN TAL > would help enormously in understanding which of the scenarios above is > dominant, and prioritize efforts for addressing the situation. I'd like to frame the discussion in context of what software developers and distributors can do to be able to include the ARIN TAL (by default) rather than focus on getting thousands of organisations to separately download & install a TAL file. The latter approach doesn't scale. We're both at NANOG next week, I'd love to sit down and have a cup of coffee. Kind regards, Job From jcurran at arin.net Tue Sep 25 22:18:00 2018 From: jcurran at arin.net (John Curran) Date: Tue, 25 Sep 2018 22:18:00 +0000 Subject: ARIN RPKI TAL deployment issues In-Reply-To: <20180925215103.GP77517@vurt.meerval.net> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <20180925210426.GO77517@vurt.meerval.net> <20180925215103.GP77517@vurt.meerval.net> Message-ID: <9C81EC45-345F-4917-9AF1-35FFEF3E4B25@arin.net> On 25 Sep 2018, at 5:51 PM, Job Snijders > wrote: ... It may make sense to associate an implicit agreement (or perhaps a license?) with the ARIN TAL to limit risks to the ARIN organisation. "Use at your own risk"-style clauses are common and acceptable. Job - We did look at using a specific set of terms (rather similar to the indeminifcation used by the RIPE in their RPKI Certification Services terms) via a referenced agreement for this purpose, but making that actually legally binding in the US legal environment is a bit challenging. Absent a specific action (such as our present “browserwrap” approach of specifically downloading the TAL), US courts have not generally recognized mere usage of software as an indication of informed consent to enter into an agreement – hence the RPA download, and why so many things in the US require some form of explicit acknowledgement in order to proceed. I'd like to frame the discussion in context of what software developers and distributors can do to be able to include the ARIN TAL (by default) rather than focus on getting thousands of organisations to separately download & install a TAL file. The latter approach doesn't scale. We're both at NANOG next week, I'd love to sit down and have a cup of coffee. Quite understandable - I suspend we’ll hear some more about these issues during David Wishnick’s session, and coffee-fueled discussion afterwards is encouraged. Thanks! /John John Curran President and CEO American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Tue Sep 25 23:11:52 2018 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 25 Sep 2018 19:11:52 -0400 Subject: ARIN RPKI TAL deployment issues In-Reply-To: <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> Message-ID: > On Sep 25, 2018, at 4:28 PM, John Curran wrote: > > On 25 Sep 2018, at 3:34 PM, Job Snijders wrote: >> >> On Tue, Sep 25, 2018 at 03:07:54PM -0400, John Curran wrote: >>> On Sep 25, 2018, at 1:30 PM, Job Snijders wrote: >>>> >>>> """Using the data, we can also see that the providers that have not >>>> downloaded the ARIN TAL. Either because they were not aware that >>>> they needed to, or could not agree to the agreement they have with >>>> it. >>> >>> Is it possible to ascertain how many of those who have not downloaded >>> the ARIN TAL are also publishing ROA’s via RIPE’s CA? >> >> I'm sure we could extend the data set to figure this out. > > It would be informative to know how many organizations potentially have concerns about the indemnification clause in the RPA but already agree to indemnification via RIPE NCC Certification Service Terms and Conditions. It would be interesting to see how much further deployment would have occurred if ARIN made it’s TAL available similar to the other locations. Thankfully we have active measurements that show that ARIN prefixes are less protected due to this. As someone that is (for personal reasons) now a voting member of ARIN, this is one of my primary concerns. My ARIN issued space is _less_ protected than if I were to have used another RIR. This devalues that investment. Instead of asking for an experiment, John I challenge you to make the ARIN TAL available and help play a role in securing the IP space within your region. There is this mantra of Secure by Default that many people have learned since the open-relay, smurf amplification and other attack days. There’s a reason my password isn’t a dictionary word, etc. If you make it easy to secure a website (eg: Lets Encrypt is a great example) there are now fewer self-signed certificates because it’s easier to do. Why is ARIN making it so hard for it’s members to get the benefits of the global ecosystem for their RIR controlled space? What makes ARIN IP space so unique in this sense? As part of a global ecosystem it’s incumbent of many of us to do the right thing here and ARIN is increasing the friction on the part of everyone to do the right thing. If I had to download the ARIN CA in order to interact with www.arin.net vs it being bundled in my browser store, would I be able to securely interact with ARIN? Therefore, I once again challenge you as part of the leadership of this organization to make the ARIN IP space as protected as those issued by the other regions. Let the developers know that if they bundle the ARIN TAL they won’t face legal action. Help bring routing security to the same ease of use as places like LetsEncrypt do for those in the SSL/TLS ecosystem. - Jared Mauch (Representing my own self/WFPL-1) From michel.py at tsisemi.com Tue Sep 25 23:55:42 2018 From: michel.py at tsisemi.com (Michel Py) Date: Tue, 25 Sep 2018 23:55:42 +0000 Subject: ARIN RPKI TAL deployment issues In-Reply-To: References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <20180925210426.GO77517@vurt.meerval.net> Message-ID: <28fcb3015d064b2a83009401fe57c8e4@CRA114.am.necel.com> John, > John Curran wrote : > 2) They could not agree to ARIN RPA agreement (for which the most cited reason is the indemnification clause, but perplexing given agreement to other indemnification clauses such as RIPE’s Certification services.) I would entertain that "could not agree to ARIN RPA" is why they don't use the TAL. I may not be representative, but I knew I had to download it. And maybe you missed a third possibility : 3) Nobody really cares about the ARIN TAL because almost nobody has validated a prefix within the ARIN region therefore installing the ARIN TAL is almost useless :-( We don't only have a problem withTAL deployment, we also have an adoption issue. And possibly an egg-and-chicken issue : nobody deploys the TAL because nobody validates their prefixes, and vice versa. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From jared at puck.nether.net Wed Sep 26 00:18:02 2018 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 25 Sep 2018 20:18:02 -0400 Subject: ARIN RPKI TAL deployment issues In-Reply-To: <28fcb3015d064b2a83009401fe57c8e4@CRA114.am.necel.com> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <20180925210426.GO77517@vurt.meerval.net> <28fcb3015d064b2a83009401fe57c8e4@CRA114.am.necel.com> Message-ID: <9E1C4B1F-9CE6-469A-874B-9022356563FD@puck.nether.net> > On Sep 25, 2018, at 7:55 PM, Michel Py wrote: > > John, > >> John Curran wrote : >> 2) They could not agree to ARIN RPA agreement (for which the most cited reason is the indemnification clause, but perplexing given agreement to other indemnification clauses such as RIPE’s Certification services.) > > I would entertain that "could not agree to ARIN RPA" is why they don't use the TAL. I may not be representative, but I knew I had to download it. > And maybe you missed a third possibility : > 3) Nobody really cares about the ARIN TAL because almost nobody has validated a prefix within the ARIN region therefore installing the ARIN TAL is almost useless :-( > > We don't only have a problem withTAL deployment, we also have an adoption issue. > And possibly an egg-and-chicken issue : nobody deploys the TAL because nobody validates their prefixes, and vice versa. Actually there are prefixes in the ARIN region with ROAs, and one would presume that issuing the ROA means you want it to be validated as well. (Similar to hosting a website on SSL vs HTTP or even gopher://) The intent is at least there, and similar to DNSSEC, publishing your DS record in the parent is part of that explicit configured intent. Saying “nobody validates their prefixes” is patently false. You may not. I may not, but there are a number of networks that are and have advertised that they are. I’m not saying you need to secure your network, but if you want to secure your routes and have an allocation from ARIN, you really need their TAL to be in the default trust store similar to how you have your PKI trust store in your OS, Browser, etc… I need my local geographic RIR to care that their anchor is included by default and to make it clear that distributing the TAL is different from _using_ the TAL. Just because I have CA roots in my browser trust store does not mean I am using them all, but if I need to it will work. On my Mac when I upgrade Xcode it often asks me to accept the License for what I downloaded. The same is true if you use gnu parallel, it outputs some wonderful legalese. There are many comparisons, which is why I’m asking that ARIN permit developers to make it easier for end-users to use the PKI material that makes the global ecosystem more complete and secure. If to start you have to edit the config file to say “I accept arin license for this”=yes would that work? We need that outreach and clarity because at present it’s not there by default and there is a communication gap between the various developers and ARIN. Those that are issuing ROAs (or are soon to) depend on this. Like I said previously, I’m going to be talking to each ARIN candidate for election this fall about this very topic and what actions they intend to do to support global secure routing. Michel, It would be a shame if you created a ROA and it could not be validated in some non-english speaking corner of the world that put your assets at risk due to this posture. The community needs secure by default for all regions and the barriers for ARIN IP space are a real and measured problem. It’s time to end this disparity as right now not all TALs are equal. They should be. - Jared From michel.py at tsisemi.com Wed Sep 26 01:20:43 2018 From: michel.py at tsisemi.com (Michel Py) Date: Wed, 26 Sep 2018 01:20:43 +0000 Subject: ARIN RPKI TAL deployment issues In-Reply-To: <9E1C4B1F-9CE6-469A-874B-9022356563FD@puck.nether.net> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <20180925210426.GO77517@vurt.meerval.net> <28fcb3015d064b2a83009401fe57c8e4@CRA114.am.necel.com> <9E1C4B1F-9CE6-469A-874B-9022356563FD@puck.nether.net> Message-ID: Jared, > Jared Mauch wrote : > Saying “nobody validates their prefixes” is patently false. You may not. I may not, but there are a number of networks that are and have advertised that they are. I did validate mine, but in the ARIN region I'm part of the only 2% that did, that's close enough to "nobody" for me, in context compared to RIPE numbers. > Michel, It would be a shame if you created a ROA and it could not be validated in some non-english speaking corner of the world that > put your assets at risk due to this posture. The community needs secure by default for all regions and the barriers for ARIN IP space > are a real and measured problem. It’s time to end this disparity as right now not all TALs are equal. They should be. I agree, but it's not that simple. The main issue I currently see with RPKI / ROA is not the ARIN TAL (altough I am directly affected) but the fact that nobody or almost nobody actually enforces RPKI. Most operators who are validating RPKI prefixes keep carrying them even when they are invalid, which makes the entire thing completely useless. And yes I know, it's not that simple ;-) And it may be shameless self-plugin, but I think we need to encourage experiments that actually try to enforce RPKI. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From jcurran at arin.net Wed Sep 26 02:55:45 2018 From: jcurran at arin.net (John Curran) Date: Wed, 26 Sep 2018 02:55:45 +0000 Subject: ARIN RPKI TAL deployment issues In-Reply-To: References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> Message-ID: <64F850AE-DD40-4D47-A006-EC152132CBDC@arin.net> On 25 Sep 2018, at 7:11 PM, Jared Mauch wrote: > > Why is ARIN making it so hard for it’s members to get the benefits of the global ecosystem for their RIR controlled space? What makes ARIN IP space so unique in this sense? As part of a global ecosystem it’s incumbent of many of us to do the right thing here and ARIN is increasing the friction on the part of everyone to do the right thing. Jared - Indeed - In the process of complying with a different legal environment, ARIN sometimes has to behave differently than RIRs that are located elsewhere... In order to protect the stability of the services we provide to all ARIN customers, we have those relying on ARIN’s certificate services indemnify ARIN from claims of damages in connection with their usage. Such indemnification isn’t unique to ARIN - RIPE has RPKI publishers indemnify RIPE, APNIC has any users of APNIC digital certificates indemnify APNIC, etc. The significant difference for ARIN is that we operate under a different legal regime, and as a matter of US law, it appears that we cannot rely only upon terms and conditions published in our website as evidence of informed agreement; i.e. within the US legal framework, we need a specific act of acceptance in order to have a binding agreement. We originally accomplished this binding via an explicit click-box acknowledgement and emailing the the TAL to agreeing party, then managed to evolve it over time to just the click-box acceptance of terms, and now are able to consider the act of simply downloading of the TAL itself as sufficient to constitute agreement to terms. Different legal regimes result in different implementations, even when the terms (such as indemnification) are similar. Thanks, /John John Curran President and CEO American Registry for Internet Numbers From morrowc.lists at gmail.com Wed Sep 26 06:09:39 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 26 Sep 2018 02:09:39 -0400 Subject: ARIN RPKI TAL deployment issues In-Reply-To: <64F850AE-DD40-4D47-A006-EC152132CBDC@arin.net> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <64F850AE-DD40-4D47-A006-EC152132CBDC@arin.net> Message-ID: (I'm going to regret posting this later, but...) On Tue, Sep 25, 2018 at 10:57 PM John Curran wrote: > > The significant difference for ARIN is that we operate under a different > legal regime, and as a matter of US law, it appears that we cannot rely > only upon terms and conditions published in our website as evidence of > informed agreement; i.e. within the US legal framework, we need a specific > act of acceptance in order to have a binding agreement. > how is arin's problem here different from that which 'lets encrypt' is facing with their Cert things? Don't they have the same sort of problem as ARIN? "somoene trusted a cert signed by LE for "thing" and got scammed/harmed/etc" It seems odd, to me anyway, that this is seemingly so very different... I also would like less friction in the RPKI process...I don't think it serves ARIN, it's community nor the global internet community to make things harder to secure/validate. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Wed Sep 26 07:02:30 2018 From: jcurran at arin.net (John Curran) Date: Wed, 26 Sep 2018 07:02:30 +0000 Subject: ARIN RPKI TAL deployment issues In-Reply-To: References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <64F850AE-DD40-4D47-A006-EC152132CBDC@arin.net> Message-ID: On 26 Sep 2018, at 1:14 AM, Benson Schliesser wrote: > Without venturing too far off topic, can you briefly compare this situation versus e.g. licensing of open source software? Often, such software is (apparently) licensed without express agreement - using bundled license files, comments inside source files, etc - and seems to accommodate the IPR and liability needs of developers and their supporting organizations. Is it ARIN's understanding that this approach is not useful for RPKI data in the US, etc? Benson - Excellent question. First and foremost, an RIR agreement which provide indemnification (such as RIPE’s RPKI publisher terms, APNIC’s Certificate user terms, and ARIN’s RPA) provides an affirmative defense regarding liability claims; i.e. effectively we are able to point out at the very beginning of proceedings that parties using RPKI data per the respective agreement definitively have all of the associated liability from such use, not the RIR. This allows for a timely disposition by a judge of any liability claims against an RIR regarding such use, which is definitely not the case of a software license agreement. In the latter case of a software license agreement, if an RIR should suffer an RPKI outage (e.g. RIPE Feb 2013 – https://www.ietf.org/mail-archive/web/sidr/current/msg05621.html), it will be necessary to show that any parties making claims of damages were harmed as the result an an ISP which had a duty to act with a certain level of care with regard to use of RPKI information and who failed in that duty, as opposed to the being the result of the RIR outage. Such an argument must be made to the satisfaction of a jury based on the preponderance of evidence – i.e. even though each ISPs would have signed an agreement to use the RPKI information “as is”, that would not preclude any case proceeding to trial and would not necessarily be sufficient for an RIR to avoid significant liability in the event of an outage and despite the clear disclaimer of “as is” provision of RPKI data. > In any case, I also look forward to hearing the Overcoming Legal Barriers to RPKI Adoption talk next week (on Monday afternoon, IIRC), and I hope that the Q&A discussion (and evening follow-up) will be helpful. Indeed – note that your question regarding a comparison to “licensing of open source software” might also be asked during that Monday session in order to gain better insight from an actual attorney (rather than my offhand knowledge of such matters...) Thanks! /John John Curran President and CEO ARIN From jcurran at arin.net Wed Sep 26 07:13:50 2018 From: jcurran at arin.net (John Curran) Date: Wed, 26 Sep 2018 07:13:50 +0000 Subject: ARIN RPKI TAL deployment issues In-Reply-To: References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <64F850AE-DD40-4D47-A006-EC152132CBDC@arin.net> Message-ID: On 26 Sep 2018, at 2:09 AM, Christopher Morrow > wrote: (I'm going to regret posting this later, but...) On Tue, Sep 25, 2018 at 10:57 PM John Curran > wrote: The significant difference for ARIN is that we operate under a different legal regime, and as a matter of US law, it appears that we cannot rely only upon terms and conditions published in our website as evidence of informed agreement; i.e. within the US legal framework, we need a specific act of acceptance in order to have a binding agreement. how is arin's problem here different from that which 'lets encrypt' is facing with their Cert things? Chris - The “Let’s encrypt” subscriber agreement (current version 1.2, 15 Nov 2018) includes "indemnify and hold harmless” clause, and parties affirmatively agree to those terms by requesting that ISRG issue a "Let’s Encrypt” Certificate to you. (I don’t know whether that process is particularly more or less onerous technically than the effort to download the ARIN TAL.) FYI, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Wed Sep 26 07:29:33 2018 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 26 Sep 2018 03:29:33 -0400 Subject: ARIN RPKI TAL deployment issues In-Reply-To: References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <64F850AE-DD40-4D47-A006-EC152132CBDC@arin.net> Message-ID: <88A00F53-325E-4BCB-898A-8B839C7D4A29@puck.nether.net> > On Sep 26, 2018, at 3:13 AM, John Curran wrote: > > On 26 Sep 2018, at 2:09 AM, Christopher Morrow wrote: >> >> (I'm going to regret posting this later, but...) >> >> On Tue, Sep 25, 2018 at 10:57 PM John Curran wrote: >> >> The significant difference for ARIN is that we operate under a different legal regime, and as a matter of US law, it appears that we cannot rely only upon terms and conditions published in our website as evidence of informed agreement; i.e. within the US legal framework, we need a specific act of acceptance in order to have a binding agreement. >> >> how is arin's problem here different from that which 'lets encrypt' is facing with their Cert things? > > Chris - > > The “Let’s encrypt” subscriber agreement (current version 1.2, 15 Nov 2018) includes "indemnify and hold harmless” clause, and parties affirmatively agree to those terms by requesting that ISRG issue a "Let’s Encrypt” Certificate to you. > > (I don’t know whether that process is particularly more or less onerous technically than the effort to download the ARIN TAL.) The process for lets encrypt is fairly straightforward, it collects some minimal information (eg: e-mail address, domain name) and then does all the voodoo necessary. If ARIN were to make this request of the developers of RPKI software, it would seem reasonable to have that passed to ARIN via some API saying “bob at example.com” typed “Agree” to the ARIN TAL as part of the initial installation of the software. For me, this is about the friction involved in making it work and while the click-through page may not seem like a barrier, there are active measurements that demonstrate it is. It may take time to communicate to the existing set of operators running RPKI validators they are missing the ARIN TAL, but I would like to ensure that new deployments don’t make this same mistake. I think this thread/communication is part of that. “Don’t forget about the extra step for ARIN”. It’s also “ARIN, please help make it easier to use your service”. With Google Maps, etc.. I may have to create an API key, it comes in multi-lingual systems in non-roman alphabet support, etc. Being part of this global ecosystem and running an RIR comes with some extra effort compared to running a corner mom & pop shop. Our actions and decisions have global consequences to the safety and security of how your and my traffic is routed. Please work with the developers for a suitable method to include the ARIN TAL by default. Come up with the click-accept legalese necessary. Since you asked, here’s what they did with the CertBot that’s commonly used by Lets Encrypt: (The first time you run the command, it will make an account, and ask for an email and agreement to the Let’s Encrypt Subscriber Agreement; you can automate those with --email and --agree-tos) If you want to use a webserver that doesn’t have full plugin support yet, you can still use “standalone” or “webroot” plugins to obtain a certificate: ./certbot-auto certonly --standalone --email admin at example.com -d example.com -d www.example.com -d other.example.net If you/ARIN could work closer with the developers of RPKI software to help make this happen that would be great. If you need introductions, I’m happy to help make them. - Jared From main at kipsang.com Wed Sep 26 07:52:07 2018 From: main at kipsang.com (Michael Bullut) Date: Wed, 26 Sep 2018 10:52:07 +0300 Subject: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1) Message-ID: Greetings Team, Has anyone deployed the aforementioned in your individual networks? A quick test suggests it is quite fast compared with Google's D.N.S. resolvers: *C:\Users\bullutm>ping 1.1.1.1* *Pinging 1.1.1.1 with 32 bytes of data:* *Reply from 1.1.1.1 : bytes=32 time=3ms TTL=61* *Reply from 1.1.1.1 : bytes=32 time=4ms TTL=61* *Reply from 1.1.1.1 : bytes=32 time=8ms TTL=61* *Reply from 1.1.1.1 : bytes=32 time=4ms TTL=61* *Ping statistics for 1.1.1.1 :* * Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),* *Approximate round trip times in milli-seconds:* * Minimum = 3ms, Maximum = 8ms, Average = 4ms* *C:\Users\bullutm>* *-------* *C:\Users\bullutm>tracert 1.1.1.1* *Tracing route to one.one.one.one [1.1.1.1]* *over a maximum of 30 hops:* * 1 4 ms 3 ms 4 ms 10.101.129.254* * 2 6 ms 20 ms 7 ms 10.98.0.165* * 3 7 ms 13 ms 15 ms 10.98.0.233* * 4 7 ms 5 ms 4 ms one.one.one.one [1.1.1.1]* *Trace complete.* *C:\Users\bullutm>* Warm regards, Michael Bullut. --- *Cell:* *+254 723 393 114.**Skype Name:* *Michael Bullut.* *Twitter:* * @Kipsang * *Blog: http://www.kipsang.com/ * *E-mail:* *main at kipsang.com
* *---* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Wed Sep 26 07:50:17 2018 From: ross at tajvar.io (Ross Tajvar) Date: Wed, 26 Sep 2018 00:50:17 -0700 Subject: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1) In-Reply-To: References: Message-ID: Do note that ping response times are not a good indicator of DNS performance. On Wed, Sep 26, 2018, 3:48 AM Michael Bullut
wrote: > Greetings Team, > > Has anyone deployed the aforementioned in your individual networks? A > quick test suggests it is quite fast compared with Google's D.N.S. > resolvers: > > *C:\Users\bullutm>ping 1.1.1.1* > > *Pinging 1.1.1.1 with 32 bytes of data:* > *Reply from 1.1.1.1 : bytes=32 time=3ms TTL=61* > *Reply from 1.1.1.1 : bytes=32 time=4ms TTL=61* > *Reply from 1.1.1.1 : bytes=32 time=8ms TTL=61* > *Reply from 1.1.1.1 : bytes=32 time=4ms TTL=61* > > *Ping statistics for 1.1.1.1 :* > * Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),* > *Approximate round trip times in milli-seconds:* > * Minimum = 3ms, Maximum = 8ms, Average = 4ms* > > *C:\Users\bullutm>* > > *-------* > > *C:\Users\bullutm>tracert 1.1.1.1* > > *Tracing route to one.one.one.one [1.1.1.1]* > *over a maximum of 30 hops:* > > * 1 4 ms 3 ms 4 ms 10.101.129.254* > * 2 6 ms 20 ms 7 ms 10.98.0.165* > * 3 7 ms 13 ms 15 ms 10.98.0.233* > * 4 7 ms 5 ms 4 ms one.one.one.one [1.1.1.1]* > > *Trace complete.* > > *C:\Users\bullutm>* > > Warm regards, > > Michael Bullut. > > --- > > *Cell:* > *+254 723 393 114.**Skype Name:* *Michael Bullut.* > *Twitter:* > * @Kipsang * > *Blog: http://www.kipsang.com/ * > *E-mail:* *main at kipsang.com
* > > *---* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From main at kipsang.com Wed Sep 26 07:59:02 2018 From: main at kipsang.com (Michael Bullut) Date: Wed, 26 Sep 2018 10:59:02 +0300 Subject: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1) In-Reply-To: References: Message-ID: Hi Ross, How would you gauge good DNS performance? Warm regards, Michael. On Wed, 26 Sep 2018 at 10:50, Ross Tajvar wrote: > Do note that ping response times are not a good indicator of DNS > performance. > > On Wed, Sep 26, 2018, 3:48 AM Michael Bullut
wrote: > >> Greetings Team, >> >> Has anyone deployed the aforementioned in your individual networks? A >> quick test suggests it is quite fast compared with Google's D.N.S. >> resolvers: >> >> *C:\Users\bullutm>ping 1.1.1.1* >> >> *Pinging 1.1.1.1 with 32 bytes of data:* >> *Reply from 1.1.1.1 : bytes=32 time=3ms TTL=61* >> *Reply from 1.1.1.1 : bytes=32 time=4ms TTL=61* >> *Reply from 1.1.1.1 : bytes=32 time=8ms TTL=61* >> *Reply from 1.1.1.1 : bytes=32 time=4ms TTL=61* >> >> *Ping statistics for 1.1.1.1 :* >> * Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),* >> *Approximate round trip times in milli-seconds:* >> * Minimum = 3ms, Maximum = 8ms, Average = 4ms* >> >> *C:\Users\bullutm>* >> >> *-------* >> >> *C:\Users\bullutm>tracert 1.1.1.1* >> >> *Tracing route to one.one.one.one [1.1.1.1]* >> *over a maximum of 30 hops:* >> >> * 1 4 ms 3 ms 4 ms 10.101.129.254* >> * 2 6 ms 20 ms 7 ms 10.98.0.165* >> * 3 7 ms 13 ms 15 ms 10.98.0.233* >> * 4 7 ms 5 ms 4 ms one.one.one.one [1.1.1.1]* >> >> *Trace complete.* >> >> *C:\Users\bullutm>* >> >> Warm regards, >> >> Michael Bullut. >> >> --- >> >> *Cell:* >> *+254 723 393 114.**Skype Name:* *Michael Bullut.* >> *Twitter:* >> * @Kipsang * >> *Blog: http://www.kipsang.com/ * >> *E-mail:* *main at kipsang.com
* >> >> *---* >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bortzmeyer at nic.fr Wed Sep 26 07:53:18 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 26 Sep 2018 09:53:18 +0200 Subject: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1) In-Reply-To: References: Message-ID: <20180926075318.rt2n77neyphtsrlt@nic.fr> On Wed, Sep 26, 2018 at 10:52:07AM +0300, Michael Bullut
wrote a message of 162 lines which said: > Has anyone deployed the aforementioned in your individual networks? > A quick test suggests it is quite fast compared with Google's > D.N.S. resolvers: Well, you don't test a DNS service with ICMP echo, for reasons you certainly know. Also, do not compare only public resolvers between themselves, also compare with a local resolver (always the closest from the clients). From bortzmeyer at nic.fr Wed Sep 26 08:15:08 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 26 Sep 2018 10:15:08 +0200 Subject: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1) In-Reply-To: References: Message-ID: <20180926081508.wdzfbi7woe25hauv@nic.fr> On Wed, Sep 26, 2018 at 10:59:02AM +0300, Michael Bullut
wrote a message of 192 lines which said: > How would you gauge good DNS performance? To test {XXX} performance, you use a {XXX} client, where XXX = DNS, HTTP, SSH, LDAP, etc. From colinj at gt86car.org.uk Wed Sep 26 08:21:21 2018 From: colinj at gt86car.org.uk (Colin Johnston) Date: Wed, 26 Sep 2018 09:21:21 +0100 Subject: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1) In-Reply-To: <20180926081508.wdzfbi7woe25hauv@nic.fr> References: <20180926081508.wdzfbi7woe25hauv@nic.fr> Message-ID: <649DBA77-B73D-4229-9A6F-796E4DC4A767@gt86car.org.uk> also could use ripe atlas Colin > On 26 Sep 2018, at 09:15, Stephane Bortzmeyer wrote: > > On Wed, Sep 26, 2018 at 10:59:02AM +0300, > Michael Bullut
wrote > a message of 192 lines which said: > >> How would you gauge good DNS performance? > > To test {XXX} performance, you use a {XXX} client, where XXX = DNS, > HTTP, SSH, LDAP, etc. > From bortzmeyer at nic.fr Wed Sep 26 09:18:27 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 26 Sep 2018 11:18:27 +0200 Subject: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1) In-Reply-To: <649DBA77-B73D-4229-9A6F-796E4DC4A767@gt86car.org.uk> References: <20180926081508.wdzfbi7woe25hauv@nic.fr> <649DBA77-B73D-4229-9A6F-796E4DC4A767@gt86car.org.uk> Message-ID: <20180926091827.s2ywizf6lf2n5aoq@nic.fr> On Wed, Sep 26, 2018 at 09:21:21AM +0100, Colin Johnston wrote a message of 16 lines which said: > also could use ripe atlas Which embeds clients for ICMP Echo, DNS, NTP, TLS, arbitrary TCP (with some hacks), and, with serious limitations, HTTP. From lists at quux.de Wed Sep 26 09:28:06 2018 From: lists at quux.de (Jens Link) Date: Wed, 26 Sep 2018 11:28:06 +0200 Subject: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1) In-Reply-To: (Michael Bullut's message of "Wed, 26 Sep 2018 10:59:02 +0300") References: Message-ID: <87in2sy5eh.fsf@pc8.berlin.quux.de> Michael Bullut
writes: > Hi Ross, > > How would you gauge good DNS performance?  quick and dirty: jens at screen:~$ dig nanog.org @8.8.8.8 | grep "Query time" ;; Query time: 16 msec jens at screen:~$ dig nanog.org @1.1.1.1 | grep "Query time" ;; Query time: 3 msec Jens From bortzmeyer at nic.fr Wed Sep 26 09:56:02 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 26 Sep 2018 11:56:02 +0200 Subject: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1) In-Reply-To: <87in2sy5eh.fsf@pc8.berlin.quux.de> References: <87in2sy5eh.fsf@pc8.berlin.quux.de> Message-ID: <20180926095602.6c3g735es5ttidgq@nic.fr> On Wed, Sep 26, 2018 at 11:28:06AM +0200, Jens Link wrote a message of 14 lines which said: > quick and dirty: Indeed. For instance, the delay depends wether the cache it hot or cold (measuring response time for an authoritative server is easier). From dot at dotat.at Wed Sep 26 10:10:55 2018 From: dot at dotat.at (Tony Finch) Date: Wed, 26 Sep 2018 11:10:55 +0100 Subject: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1) In-Reply-To: <87in2sy5eh.fsf@pc8.berlin.quux.de> References: <87in2sy5eh.fsf@pc8.berlin.quux.de> Message-ID: Jens Link wrote: > > jens at screen:~$ dig nanog.org @8.8.8.8 | grep "Query time" > ;; Query time: 16 msec > jens at screen:~$ dig nanog.org @1.1.1.1 | grep "Query time" > ;; Query time: 3 msec You can use dig -u to get microsecond resolution, e.g. $ dig -u @131.111.8.42 nanog.org | grep time: ;; Query time: 611 usec Tony. -- f.anthony.n.finch http://dotat.at/ work to the benefit of all From dot at dotat.at Wed Sep 26 10:42:16 2018 From: dot at dotat.at (Tony Finch) Date: Wed, 26 Sep 2018 11:42:16 +0100 Subject: ARIN RPKI TAL deployment issues In-Reply-To: References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <64F850AE-DD40-4D47-A006-EC152132CBDC@arin.net> Message-ID: John Curran wrote: > On 26 Sep 2018, at 2:09 AM, Christopher Morrow > wrote: > > > > how is arin's problem here different from that which 'lets encrypt' is > > facing with their Cert things? > > The “Let’s encrypt” subscriber agreement (current version 1.2, 15 Nov > 2018) includes "indemnify and hold harmless” clause, and parties > affirmatively agree to those terms by requesting that ISRG issue a > "Let’s Encrypt” Certificate to you. The difference is that the Let's Encrypt agreement is for people obtaining certificates from them. The ARIN equivalent would be the agreement for ARIN members. Let's Encrypt does not require an agreement from relying parties (i.e. browser users), whereas ARIN does. Tony. -- f.anthony.n.finch http://dotat.at/ Rockall, Malin, Hebrides: Southwest veering northwest, 5 to 7, perhaps gale 8 later, but cyclonic 3 or 4 for a time. Rough or very rough. Rain or showers. Good occasionally poor. From jcurran at arin.net Wed Sep 26 11:07:49 2018 From: jcurran at arin.net (John Curran) Date: Wed, 26 Sep 2018 11:07:49 +0000 Subject: ARIN RPKI TAL deployment issues In-Reply-To: References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <64F850AE-DD40-4D47-A006-EC152132CBDC@arin.net> Message-ID: On 26 Sep 2018, at 6:42 AM, Tony Finch wrote: > > John Curran wrote: >> On 26 Sep 2018, at 2:09 AM, Christopher Morrow > wrote: >>> >>> how is arin's problem here different from that which 'lets encrypt' is >>> facing with their Cert things? >> >> The “Let’s encrypt” subscriber agreement (current version 1.2, 15 Nov >> 2018) includes "indemnify and hold harmless” clause, and parties >> affirmatively agree to those terms by requesting that ISRG issue a >> "Let’s Encrypt” Certificate to you. > > The difference is that the Let's Encrypt agreement is for people obtaining > certificates from them. The ARIN equivalent would be the agreement for > ARIN members. > > Let's Encrypt does not require an agreement from relying parties (i.e. > browser users), whereas ARIN does. Tony - That is correct; I did not say that they were parallel situations, only pointing out that the Let’s Encrypt folks also go beyond simply providing services “as is”, and require indemnification from those engaging their CA services, just as ARIN, RIPE, APNIC do… ARIN and APNIC go further by having indemnification by parties using information in the CA; in ARIN’s case, this requires an explicit act of acceptance to be legally valid. Thanks! /John John Curran President and CEO ARIN From nanog at ics-il.net Wed Sep 26 11:14:10 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 26 Sep 2018 06:14:10 -0500 (CDT) Subject: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1) In-Reply-To: References: Message-ID: <1098801922.1053.1537960445113.JavaMail.mhammett@ThunderFuck> I recommend that eyeball networks don't run any external recursive server for optimal CDN performance. Yes, some CDNs support other methods, but not all. If not all do, then the requirement remains. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Michael Bullut"
To: nanog at nanog.org Sent: Wednesday, September 26, 2018 2:52:07 AM Subject: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1) Greetings Team, Has anyone deployed the aforementioned in your individual networks? A quick test suggests it is quite fast compared with Google's D.N.S. resolvers: C:\Users\bullutm>ping 1.1.1.1 Pinging 1.1.1.1 with 32 bytes of data: Reply from 1.1.1.1 : bytes=32 time=3ms TTL=61 Reply from 1.1.1.1 : bytes=32 time=4ms TTL=61 Reply from 1.1.1.1 : bytes=32 time=8ms TTL=61 Reply from 1.1.1.1 : bytes=32 time=4ms TTL=61 Ping statistics for 1.1.1.1 : Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 3ms, Maximum = 8ms, Average = 4ms C:\Users\bullutm> ------- C:\Users\bullutm>tracert 1.1.1.1 Tracing route to one.one.one.one [1.1.1.1] over a maximum of 30 hops: 1 4 ms 3 ms 4 ms 10.101.129.254 2 6 ms 20 ms 7 ms 10.98.0.165 3 7 ms 13 ms 15 ms 10.98.0.233 4 7 ms 5 ms 4 ms one.one.one.one [1.1.1.1] Trace complete. C:\Users\bullutm> Warm regards, Michael Bullut. --- Cell: +254 723 393 114. Skype Name: Michael Bullut. Twitter: @Kipsang Blog: http://www.kipsang.com/ E-mail: main at kipsang.com --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Wed Sep 26 11:16:35 2018 From: jcurran at arin.net (John Curran) Date: Wed, 26 Sep 2018 11:16:35 +0000 Subject: ARIN RPKI TAL deployment issues In-Reply-To: <88A00F53-325E-4BCB-898A-8B839C7D4A29@puck.nether.net> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <64F850AE-DD40-4D47-A006-EC152132CBDC@arin.net> <88A00F53-325E-4BCB-898A-8B839C7D4A29@puck.nether.net> Message-ID: On 26 Sep 2018, at 3:29 AM, Jared Mauch wrote: > > The process for lets encrypt is fairly straightforward, it collects some minimal information (eg: e-mail address, domain name) and then does all the voodoo necessary. If ARIN were to make this request of the developers of RPKI software, it would seem reasonable to have that passed to ARIN via some API saying “bob at example.com” typed “Agree” to the ARIN TAL as part of the initial installation of the software. Jared - Interesting point – thank you for the very clear elaboration of this particular issue. Would it suffice if ARIN made clear in its RPKI information that software installation tools may download the ARIN TAL on behalf of a party so long as the parry agrees to statement displayed which reads “This software utilizes information from the ARIN Certificate Authority, and such usage is subject to the ARIN Relying Party Agreement. Type ‘Agree’ to proceed” ? > Please work with the developers for a suitable method to include the ARIN TAL by default. Come up with the click-accept legalese necessary. > > Since you asked, here’s what they did with the CertBot that’s commonly used by Lets Encrypt: > > (The first time you run the command, it will make an account, and ask for an email and agreement to the Let’s Encrypt Subscriber Agreement; you can automate those with --email and --agree-tos) Acknowledged; I believe that allowing something similar to enable software installation tools to download the ARIN TAL for a party should be relatively straightforward – I will research that asap. Thanks! /John John Curran President and CEO ARIN From niels=nanog at bakker.net Wed Sep 26 11:34:44 2018 From: niels=nanog at bakker.net (niels=nanog at bakker.net) Date: Wed, 26 Sep 2018 13:34:44 +0200 Subject: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1) In-Reply-To: <1098801922.1053.1537960445113.JavaMail.mhammett@ThunderFuck> References: <1098801922.1053.1537960445113.JavaMail.mhammett@ThunderFuck> Message-ID: <20180926113444.GA7993@jima.tpb.net> * nanog at ics-il.net (Mike Hammett) [Wed 26 Sep 2018, 13:14 CEST]: >I recommend that eyeball networks don't run any external recursive >server for optimal CDN performance. Yes, some CDNs support other >methods, but not all. If not all do, then the requirement remains. +1 https://blog.powerdns.com/2018/09/04/on-firefox-moving-dns-to-a-third-party/ -- Niels. From nanog at ics-il.net Wed Sep 26 11:59:00 2018 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 26 Sep 2018 06:59:00 -0500 (CDT) Subject: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1) In-Reply-To: <20180926113444.GA7993@jima.tpb.net> References: <1098801922.1053.1537960445113.JavaMail.mhammett@ThunderFuck> <20180926113444.GA7993@jima.tpb.net> Message-ID: <1890050598.1117.1537963139090.JavaMail.mhammett@ThunderFuck> Seems like a good reason to not use Firefox. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: niels=nanog at bakker.net To: nanog at nanog.org Sent: Wednesday, September 26, 2018 6:34:44 AM Subject: Re: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1) * nanog at ics-il.net (Mike Hammett) [Wed 26 Sep 2018, 13:14 CEST]: >I recommend that eyeball networks don't run any external recursive >server for optimal CDN performance. Yes, some CDNs support other >methods, but not all. If not all do, then the requirement remains. +1 https://blog.powerdns.com/2018/09/04/on-firefox-moving-dns-to-a-third-party/ -- Niels. -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Wed Sep 26 12:21:09 2018 From: job at ntt.net (Job Snijders) Date: Wed, 26 Sep 2018 12:21:09 +0000 Subject: ARIN RPKI TAL deployment issues In-Reply-To: References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <64F850AE-DD40-4D47-A006-EC152132CBDC@arin.net> Message-ID: <20180926122109.GR77517@vurt.meerval.net> On Wed, Sep 26, 2018 at 11:07:49AM +0000, John Curran wrote: > > Let's Encrypt does not require an agreement from relying parties > > (i.e. browser users), whereas ARIN does. > > That is correct; I did not say that they were parallel situations, > only pointing out that the Let’s Encrypt folks also go beyond simply > providing services “as is”, and require indemnification from those > engaging their CA services, just as ARIN, RIPE, APNIC do… Indeed, you can download the Let's Encrypt CA here: https://letsencrypt.org/certificates/ no mention of indemnification, restrictions, liability, limitations or an agreement. > ARIN and APNIC go further by having indemnification by parties using > information in the CA; in ARIN’s case, this requires an explicit act > of acceptance to be legally valid. Are you sure about APNIC? The APNIC TAL is available here in a plain and simple format: https://www.apnic.net/community/security/resource-certification/apnic-rpki-trust-anchor-locator/ no mention of indemnification, restrictions, liability, limitations or an agreement If we take a look at other important PKI root certificates: https://www.geotrust.com/resources/root-certificates/ quote: "There is no charge for use under these terms and You are not required to sign the agreement to make use of the Root Certificates." https://www.iana.org/dnssec/files *all* of DNSSEC depends on this one, no mention of indemnification, restrictions, liability, limitations or an agreement https://support.comodo.com/index.php?/Knowledgebase/List/Index/71 no mention of indemnification, restrictions, liability, limitations or an agreement https://support.globalsign.com/customer/en/portal/articles/1426602-globalsign-root-certificates no mention of indemnification, restrictions, liability, limitations or an agreement The list goes on and on... What makes ARIN's situation unique compared to other PKI systems and certificate authorities? I only see examples where relying parties are accomodated in every possible way for access to the root certificates. Shouldn't the indemnification be just between ARIN and the resource holder? Is there really a necessity to have relying parties agree to anything? Kind regards, Job From jcurran at arin.net Wed Sep 26 12:56:26 2018 From: jcurran at arin.net (John Curran) Date: Wed, 26 Sep 2018 12:56:26 +0000 Subject: ARIN RPKI TAL deployment issues In-Reply-To: <20180926122109.GR77517@vurt.meerval.net> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <64F850AE-DD40-4D47-A006-EC152132CBDC@arin.net> <20180926122109.GR77517@vurt.meerval.net> Message-ID: <52F2D40A-B3AA-4732-BDF0-E1C6250C8F48@arin.net> On 26 Sep 2018, at 8:21 AM, Job Snijders > wrote: ARIN and APNIC go further by having indemnification by parties using information in the CA; in ARIN’s case, this requires an explicit act of acceptance to be legally valid. Are you sure about APNIC? The APNIC TAL is available here in a plain and simple format: https://www.apnic.net/community/security/resource-certification/apnic-rpki-trust-anchor-locator/ no mention of indemnification, restrictions, liability, limitations or an agreement Job - From "CA Terms & Conditions APNIC’s Certification Authority (CA) services are provided under the following terms and conditions: ... • The recipient of any Digital Certificates issued by the APNIC CA service will indemnify APNIC against any and all claims by third parties for damages of any kind arising from the use of that certificate.” I imagine that folks are not aware of that (just as they are unaware of the indemnification in most RIR service agreements) due to absence of any requirement to explicitly acknowledge same. What makes ARIN's situation unique compared to other PKI systems and certificate authorities? I only see examples where relying parties are accomodated in every possible way for access to the root certificates. The requirement upon relying parties is not unique among RIRs - see above re APNIC. There is nothing inherent to PKI that requires specific terms (e.g. indemnification for damages arising from use), but it should not be surprising that the PKI use for routing validation poses the opportunity for very significant damage claims if not done by every network operator according to best practices. In the case of ARIN, this does necessitate indemnification in order to reduce risk exposure to the overall RIR mission. Thanks, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Wed Sep 26 13:26:51 2018 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 26 Sep 2018 09:26:51 -0400 Subject: ARIN RPKI TAL deployment issues In-Reply-To: References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <64F850AE-DD40-4D47-A006-EC152132CBDC@arin.net> <88A00F53-325E-4BCB-898A-8B839C7D4A29@puck.nether.net> Message-ID: <47AC95D7-D607-4EFC-8F74-8E786EC71DE6@puck.nether.net> > On Sep 26, 2018, at 7:16 AM, John Curran wrote: > > On 26 Sep 2018, at 3:29 AM, Jared Mauch wrote: >> >> The process for lets encrypt is fairly straightforward, it collects some minimal information (eg: e-mail address, domain name) and then does all the voodoo necessary. If ARIN were to make this request of the developers of RPKI software, it would seem reasonable to have that passed to ARIN via some API saying “bob at example.com” typed “Agree” to the ARIN TAL as part of the initial installation of the software. > > Jared - > > Interesting point – thank you for the very clear elaboration of this particular issue. John, Thank you for listening :-) > Would it suffice if ARIN made clear in its RPKI information that software installation tools may download the ARIN TAL on behalf of a party so long as the parry agrees to statement displayed which reads “This software utilizes information from the ARIN Certificate Authority, and such usage is subject to the ARIN Relying Party Agreement. Type ‘Agree’ to proceed” ? I think this would help, but ideally you would allow people (software vendors) to package the TAL and if they type ‘Agree’ it would allow use of it. >> Please work with the developers for a suitable method to include the ARIN TAL by default. Come up with the click-accept legalese necessary. >> >> Since you asked, here’s what they did with the CertBot that’s commonly used by Lets Encrypt: >> >> (The first time you run the command, it will make an account, and ask for an email and agreement to the Let’s Encrypt Subscriber Agreement; you can automate those with --email and --agree-tos) > > Acknowledged; I believe that allowing something similar to enable software installation tools to download the ARIN TAL for a party should be relatively straightforward – I will research that asap. Thank you! This and/or guidance to software developers about this being a permissible action on their part. This should help improve things. - Jared From jcurran at arin.net Wed Sep 26 13:30:42 2018 From: jcurran at arin.net (John Curran) Date: Wed, 26 Sep 2018 13:30:42 +0000 Subject: ARIN RPKI TAL deployment issues In-Reply-To: <47AC95D7-D607-4EFC-8F74-8E786EC71DE6@puck.nether.net> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <64F850AE-DD40-4D47-A006-EC152132CBDC@arin.net> <88A00F53-325E-4BCB-898A-8B839C7D4A29@puck.nether.net> <47AC95D7-D607-4EFC-8F74-8E786EC71DE6@puck.nether.net> Message-ID: On 26 Sep 2018, at 9:26 AM, Jared Mauch wrote: >> On Sep 26, 2018, at 7:16 AM, John Curran wrote: >> >> On 26 Sep 2018, at 3:29 AM, Jared Mauch wrote: >>> >>> The process for lets encrypt is fairly straightforward, it collects some minimal information (eg: e-mail address, domain name) and then does all the voodoo necessary. If ARIN were to make this request of the developers of RPKI software, it would seem reasonable to have that passed to ARIN via some API saying “bob at example.com” typed “Agree” to the ARIN TAL as part of the initial installation of the software. >> >> Jared - >> >> Interesting point – thank you for the very clear elaboration of this particular issue. > > John, > > Thank you for listening :-) Jared - No problem at all – I work for you (i.e. the collective “you" on this mailing list.) >> Would it suffice if ARIN made clear in its RPKI information that software installation tools may download the ARIN TAL on behalf of a party so long as the parry agrees to statement displayed which reads “This software utilizes information from the ARIN Certificate Authority, and such usage is subject to the ARIN Relying Party Agreement. Type ‘Agree’ to proceed” ? > > I think this would help, but ideally you would allow people (software vendors) to package the TAL and if they type ‘Agree’ it would allow use of it. Got it - I’ll look to this approach if at all possible. >>> Please work with the developers for a suitable method to include the ARIN TAL by default. Come up with the click-accept legalese necessary. >>> >>> Since you asked, here’s what they did with the CertBot that’s commonly used by Lets Encrypt: >>> >>> (The first time you run the command, it will make an account, and ask for an email and agreement to the Let’s Encrypt Subscriber Agreement; you can automate those with --email and --agree-tos) >> >> Acknowledged; I believe that allowing something similar to enable software installation tools to download the ARIN TAL for a party should be relatively straightforward – I will research that asap. > > Thank you! This and/or guidance to software developers about this being a permissible action on their part. This should help improve things. Thanks for the thoughtful discussion - very helpful! /John John Curran President and CEO ARIN From morrowc.lists at gmail.com Wed Sep 26 14:20:10 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 26 Sep 2018 10:20:10 -0400 Subject: ARIN RPKI TAL deployment issues In-Reply-To: References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <64F850AE-DD40-4D47-A006-EC152132CBDC@arin.net> Message-ID: On Wed, Sep 26, 2018 at 6:42 AM Tony Finch wrote: > > Let's Encrypt does not require an agreement from relying parties (i.e. > browser users), whereas ARIN does. > > this was my point, sorry for muddying things. (see 'regret' comment earlier) -------------- next part -------------- An HTML attachment was scrubbed... URL: From bensons at queuefull.net Wed Sep 26 05:14:20 2018 From: bensons at queuefull.net (Benson Schliesser) Date: Wed, 26 Sep 2018 01:14:20 -0400 Subject: ARIN RPKI TAL deployment issues In-Reply-To: <64F850AE-DD40-4D47-A006-EC152132CBDC@arin.net> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <64F850AE-DD40-4D47-A006-EC152132CBDC@arin.net> Message-ID: Hi, John. On Tue, Sep 25, 2018, 22:56 John Curran wrote: > > Indeed - In the process of complying with a different legal environment, > ARIN sometimes has to behave differently than RIRs that are located > elsewhere... > > [...] > > The significant difference for ARIN is that we operate under a different > legal regime, and as a matter of US law, it appears that we cannot rely > only upon terms and conditions published in our website as evidence of > informed agreement; i.e. within the US legal framework, we need a specific > act of acceptance in order to have a binding agreement. > Without venturing too far off topic, can you briefly compare this situation versus e.g. licensing of open source software? Often, such software is (apparently) licensed without express agreement - using bundled license files, comments inside source files, etc - and seems to accommodate the IPR and liability needs of developers and their supporting organizations. Is it ARIN's understanding that this approach is not useful for RPKI data in the US, etc? In any case, I also look forward to hearing the Overcoming Legal Barriers to RPKI Adoption talk next week (on Monday afternoon, IIRC), and I hope that the Q&A discussion (and evening follow-up) will be helpful. Thanks, -Benson -------------- next part -------------- An HTML attachment was scrubbed... URL: From cjeker at diehard.n-r-g.com Wed Sep 26 08:02:16 2018 From: cjeker at diehard.n-r-g.com (Claudio Jeker) Date: Wed, 26 Sep 2018 10:02:16 +0200 Subject: ARIN RPKI TAL deployment issues In-Reply-To: <88A00F53-325E-4BCB-898A-8B839C7D4A29@puck.nether.net> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <64F850AE-DD40-4D47-A006-EC152132CBDC@arin.net> <88A00F53-325E-4BCB-898A-8B839C7D4A29@puck.nether.net> Message-ID: <20180926080216.GA10058@diehard.n-r-g.com> On Wed, Sep 26, 2018 at 03:29:33AM -0400, Jared Mauch wrote: > > > > On Sep 26, 2018, at 3:13 AM, John Curran wrote: > > > > On 26 Sep 2018, at 2:09 AM, Christopher Morrow wrote: > >> > >> (I'm going to regret posting this later, but...) > >> > >> On Tue, Sep 25, 2018 at 10:57 PM John Curran wrote: > >> > >> The significant difference for ARIN is that we operate under a different legal regime, and as a matter of US law, it appears that we cannot rely only upon terms and conditions published in our website as evidence of informed agreement; i.e. within the US legal framework, we need a specific act of acceptance in order to have a binding agreement. > >> > >> how is arin's problem here different from that which 'lets encrypt' is facing with their Cert things? > > > > Chris - > > > > The “Let’s encrypt” subscriber agreement (current version 1.2, 15 Nov 2018) includes "indemnify and hold harmless” clause, and parties affirmatively agree to those terms by requesting that ISRG issue a "Let’s Encrypt” Certificate to you. > > > > (I don’t know whether that process is particularly more or less onerous technically than the effort to download the ARIN TAL.) > > The process for lets encrypt is fairly straightforward, it collects some minimal information (eg: e-mail address, domain name) and then does all the voodoo necessary. If ARIN were to make this request of the developers of RPKI software, it would seem reasonable to have that passed to ARIN via some API saying “bob at example.com” typed “Agree” to the ARIN TAL as part of the initial installation of the software. > > For me, this is about the friction involved in making it work and while the click-through page may not seem like a barrier, there are active measurements that demonstrate it is. It may take time to communicate to the existing set of operators running RPKI validators they are missing the ARIN TAL, but I would like to ensure that new deployments don’t make this same mistake. > > I think this thread/communication is part of that. “Don’t forget about the extra step for ARIN”. It’s also “ARIN, please help make it easier to use your service”. > > With Google Maps, etc.. I may have to create an API key, it comes in multi-lingual systems in non-roman alphabet support, etc. Being part of this global ecosystem and running an RIR comes with some extra effort compared to running a corner mom & pop shop. Our actions and decisions have global consequences to the safety and security of how your and my traffic is routed. > > Please work with the developers for a suitable method to include the ARIN TAL by default. Come up with the click-accept legalese necessary. > > Since you asked, here’s what they did with the CertBot that’s commonly used by Lets Encrypt: > > > (The first time you run the command, it will make an account, and ask for an email and agreement to the Let’s Encrypt Subscriber Agreement; you can automate those with --email and --agree-tos) > > If you want to use a webserver that doesn’t have full plugin support yet, you can still use “standalone” or “webroot” plugins to obtain a certificate: > > ./certbot-auto certonly --standalone --email admin at example.com -d example.com -d www.example.com -d other.example.net > > If you/ARIN could work closer with the developers of RPKI software to help make this happen that would be great. If you need introductions, I’m happy to help make them. > This is the wrong side of the system. If you want to compare the ARIN TAL to anything related to letsencrypt then it is the TLS root certificates which are shipped by all OS and browsers. This discussion is not about the process to get a cerificate (or ROA entry signed) this is about shipping the trust anchor, which makes the system actually work. As an opensource developer what I need is to be able to ship the public key together with my software so that the verification works out of the box. Without the public key (TAL) none of the ARIN ROA entries can be validated. I do not understand why a public key is under a click-accept license. If fear of indemnification is an issue then how is it possible that so many US public keys are shipped with the TLS/SSL root certificates without any issue? ARIN can still use the same license for customers wanting to add entries to the ARIN RPKI database. It is just about the fact that a 3rd party that has nothing todo with ARIN needs to accept their licence to be able to verify that the ARIN signed ROA entry is acctually valid. No other validation system (DNSSEC, TLS/SSL) is doing that. It is actually in the interest of ARIN and all ARIN members that the TAL is as widely distributed as possible since only then adding a ROA actually gives you the intended benefit. -- :wq Claudio From yradzin at gmail.com Wed Sep 26 13:03:52 2018 From: yradzin at gmail.com (Yoni Radzin) Date: Wed, 26 Sep 2018 09:03:52 -0400 Subject: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1) In-Reply-To: References: Message-ID: <16C1594D-E662-4805-B3BD-67A70811D36E@gmail.com> For Window’s clients, you might want to try out this freeware GRC tool for benchmarking DNS performance: https://www.grc.com/dns/benchmark.htm Cheers -- Yonatan (Yoni) Radzin yradzin at gmail.com > On Sep 26, 2018, at 3:59 AM, Michael Bullut
wrote: > > Hi Ross, > > How would you gauge good DNS performance? > > Warm regards, > > Michael. > > >> On Wed, 26 Sep 2018 at 10:50, Ross Tajvar wrote: >> Do note that ping response times are not a good indicator of DNS performance. >> >>> On Wed, Sep 26, 2018, 3:48 AM Michael Bullut
wrote: >>> Greetings Team, >>> >>> Has anyone deployed the aforementioned in your individual networks? A quick test suggests it is quite fast compared with Google's D.N.S. resolvers: >>> >>> C:\Users\bullutm>ping 1.1.1.1 >>> >>> Pinging 1.1.1.1 with 32 bytes of data: >>> Reply from 1.1.1.1: bytes=32 time=3ms TTL=61 >>> Reply from 1.1.1.1: bytes=32 time=4ms TTL=61 >>> Reply from 1.1.1.1: bytes=32 time=8ms TTL=61 >>> Reply from 1.1.1.1: bytes=32 time=4ms TTL=61 >>> >>> Ping statistics for 1.1.1.1: >>> Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), >>> Approximate round trip times in milli-seconds: >>> Minimum = 3ms, Maximum = 8ms, Average = 4ms >>> >>> C:\Users\bullutm> >>> >>> ------- >>> >>> C:\Users\bullutm>tracert 1.1.1.1 >>> >>> Tracing route to one.one.one.one [1.1.1.1] >>> over a maximum of 30 hops: >>> >>> 1 4 ms 3 ms 4 ms 10.101.129.254 >>> 2 6 ms 20 ms 7 ms 10.98.0.165 >>> 3 7 ms 13 ms 15 ms 10.98.0.233 >>> 4 7 ms 5 ms 4 ms one.one.one.one [1.1.1.1] >>> >>> Trace complete. >>> >>> C:\Users\bullutm> >>> >>> Warm regards, >>> >>> Michael Bullut. >>> >>> --- >>> >>> Cell: +254 723 393 114. >>> Skype Name: Michael Bullut. >>> Twitter: @Kipsang >>> Blog: http://www.kipsang.com/ >>> E-mail: main at kipsang.com >>> >>> --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From dot at dotat.at Wed Sep 26 15:02:04 2018 From: dot at dotat.at (Tony Finch) Date: Wed, 26 Sep 2018 16:02:04 +0100 Subject: ARIN RPKI TAL deployment issues In-Reply-To: <52F2D40A-B3AA-4732-BDF0-E1C6250C8F48@arin.net> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <64F850AE-DD40-4D47-A006-EC152132CBDC@arin.net> <20180926122109.GR77517@vurt.meerval.net> <52F2D40A-B3AA-4732-BDF0-E1C6250C8F48@arin.net> Message-ID: John Curran wrote: > > From > > "CA Terms & Conditions > > APNIC’s Certification Authority (CA) services are provided under the > following terms and conditions: ... > > • The recipient of any Digital Certificates issued by the APNIC CA > service will indemnify APNIC against any and all claims by third parties > for damages of any kind arising from the use of that certificate.” That's about certificates, not about trust anchors. It applies to APNIC members and account holders, not to relying parties. Tony. -- f.anthony.n.finch http://dotat.at/ Forth: West or southwest 5 to 7, occasionally gale 8 for a time. Moderate. Rain later. Good, occasionally moderate later. From jcurran at arin.net Wed Sep 26 15:48:22 2018 From: jcurran at arin.net (John Curran) Date: Wed, 26 Sep 2018 15:48:22 +0000 Subject: ARIN RPKI TAL deployment issues In-Reply-To: References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <64F850AE-DD40-4D47-A006-EC152132CBDC@arin.net> <20180926122109.GR77517@vurt.meerval.net> <52F2D40A-B3AA-4732-BDF0-E1C6250C8F48@arin.net> Message-ID: <311684FC-A45C-4F99-B560-0F6BDDBC4CAE@arin.net> On 26 Sep 2018, at 11:02 AM, Tony Finch > wrote: John Curran > wrote: From "CA Terms & Conditions APNIC’s Certification Authority (CA) services are provided under the following terms and conditions: ... • The recipient of any Digital Certificates issued by the APNIC CA service will indemnify APNIC against any and all claims by third parties for damages of any kind arising from the use of that certificate.” That's about certificates, not about trust anchors. It applies to APNIC members and account holders, not to relying parties. Tony - Interesting assertion… while APNIC does issue digital certificates to APNIC customers for identity authentication purposes, it also issues digital certificates for RPKI. It’s possible that the intent that the term “Digital Certificates” (capitalized) in the CA Terms and Conditions refers to only to those within APNIC’s identity CA, but the argument against that would be APNIC’s online information about "Digital Certificates" - === From ) What is a Digital Certificate? Digital Certificates bind an identity to a pair of electronic keys that can be used to encrypt and sign digital information. APNIC uses electronic certificates to prove its own identity, the identity of its Members, and the right-of-use over Internet resources. APNIC issues regular Public Key Infrastructure (PKI) certificates for access control to APNIC services such as the MyAPNIC Member services website. In the case of Resource Certification, APNIC issues Resource Public Key Infrastructure (RPKI) certificates that have ‘Certificate Extensions’ added. These Certificate Extensions carry the Internet number resources allocated or assigned to the APNIC Member who is the subject of the Resource Certificate. These Resource Certificates are different to the identity certificates used for Web system access, and may only be used in the context of verifying an entity’s “right-of-use” over an IP address or AS. As a result, APNIC now manages two independent certificate authorities, one for Member services, and the second for Resource Certification. … === Given that APNIC explicitly mentions the RPKI electronic certificates in their explanation of what Digital Certificates are (and further noting that ROA’s do indeed contain within them end-entity resource certificates with keys for verification), APNIC”s overall CA Terms and Conditions, including the referenced indemnification clause, would appear to be applicable to their RPKI CA services. If the intent was indeed to limit the scope, then then APNIC could have easily used the term “Identity Certificates” in the indemnification clause to make clear its limited scope; i.e. if you’re particularly concerned about liability from the resulting indemnification, it might be best to get this clarified one way or the other from APNIC. Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattlists at rivervalleyinternet.net Wed Sep 26 18:00:03 2018 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Wed, 26 Sep 2018 14:00:03 -0400 Subject: Deploying IPv6 XLAT64 Message-ID: <20ae0d18-88cc-03f9-207d-856a8564fa14@rivervalleyinternet.net> Looking at getting into IPv6 here ourselves... one of the big hold ups has been the dual stacking. Can anyone recommend a quality, not ridiculously convoluted to setup, XLAT64 translator that we could run in our network to take the IPv6 to an IPv4 address when the remote server doesn't have 6 capability? From johnl at iecc.com Wed Sep 26 18:05:05 2018 From: johnl at iecc.com (John Levine) Date: 26 Sep 2018 11:05:05 -0700 Subject: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1) In-Reply-To: <87in2sy5eh.fsf@pc8.berlin.quux.de> Message-ID: <20180926180506.7CE06200546CE0@ary.local> In article <87in2sy5eh.fsf at pc8.berlin.quux.de> you write: >quick and dirty: > >jens at screen:~$ dig nanog.org @8.8.8.8 | grep "Query time" >;; Query time: 16 msec >jens at screen:~$ dig nanog.org @1.1.1.1 | grep "Query time" >;; Query time: 3 msec Yeah, that's super reliable: $ drill nanog.org @1.1.1.1 | grep "Query time" ;; Query time: 31 msec $ drill nanog.org @1.1.1.1 | grep "Query time" ;; Query time: 18 msec From jordi.palet at consulintel.es Wed Sep 26 18:19:43 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 26 Sep 2018 15:19:43 -0300 Subject: Deploying IPv6 XLAT64 In-Reply-To: <20ae0d18-88cc-03f9-207d-856a8564fa14@rivervalleyinternet.net> References: <20ae0d18-88cc-03f9-207d-856a8564fa14@rivervalleyinternet.net> Message-ID: You can use Jool for both 464XLAT and just NAT64. I've done a workshop on this at the LACNIC meeting this week. See slides 43 and next ones: http://www.lacnic.net/innovaportal/file/3139/1/ipv6-only_v11_16-9.pdf Saludos, Jordi -----Mensaje original----- De: NANOG en nombre de Matt Hoppes Fecha: miércoles, 26 de septiembre de 2018, 15:03 Para: North American Network Operators' Group Asunto: Deploying IPv6 XLAT64 Looking at getting into IPv6 here ourselves... one of the big hold ups has been the dual stacking. Can anyone recommend a quality, not ridiculously convoluted to setup, XLAT64 translator that we could run in our network to take the IPv6 to an IPv4 address when the remote server doesn't have 6 capability? ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From mattlists at rivervalleyinternet.net Wed Sep 26 18:22:03 2018 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Wed, 26 Sep 2018 14:22:03 -0400 Subject: Deploying IPv6 XLAT64 In-Reply-To: References: <20ae0d18-88cc-03f9-207d-856a8564fa14@rivervalleyinternet.net> Message-ID: Thanks... that is what I don't understand: Why is NAT64 such a difficult concept to put into routers and firewalls? We already do NAT with IPv4 just fine. I feel like IPv6 adoption would be much faster if there was a transition mechanism other than dual stacking. Think: Corporate offices. Rather than renumbering everything inside, they just turn on NAT64 and now they can begin a slow and controlled transition. On 9/26/18 2:19 PM, JORDI PALET MARTINEZ wrote: > You can use Jool for both 464XLAT and just NAT64. > > I've done a workshop on this at the LACNIC meeting this week. See slides 43 and next ones: > > http://www.lacnic.net/innovaportal/file/3139/1/ipv6-only_v11_16-9.pdf > > Saludos, > Jordi > > > > -----Mensaje original----- > De: NANOG en nombre de Matt Hoppes > Fecha: miércoles, 26 de septiembre de 2018, 15:03 > Para: North American Network Operators' Group > Asunto: Deploying IPv6 XLAT64 > > Looking at getting into IPv6 here ourselves... one of the big hold ups > has been the dual stacking. > > Can anyone recommend a quality, not ridiculously convoluted to setup, > XLAT64 translator that we could run in our network to take the IPv6 to > an IPv4 address when the remote server doesn't have 6 capability? > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > From jordi.palet at consulintel.es Wed Sep 26 18:24:51 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 26 Sep 2018 15:24:51 -0300 Subject: Deploying IPv6 XLAT64 In-Reply-To: References: <20ae0d18-88cc-03f9-207d-856a8564fa14@rivervalleyinternet.net> Message-ID: <3E307E8B-153B-4E3E-A9CC-D8E60F7C62DD@consulintel.es> This document, which is already in the IESG review, may answer your question: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ Also take a look into this one: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ Remember that if your enterprise network has apps that use literals, or they don't support IPv6, you still need dual-stack in the LANs, but access IPv6-only is just fine. Regards, Jordi -----Mensaje original----- De: Matt Hoppes Fecha: miércoles, 26 de septiembre de 2018, 15:22 Para: JORDI PALET MARTINEZ , North American Network Operators' Group Asunto: Re: Deploying IPv6 XLAT64 Thanks... that is what I don't understand: Why is NAT64 such a difficult concept to put into routers and firewalls? We already do NAT with IPv4 just fine. I feel like IPv6 adoption would be much faster if there was a transition mechanism other than dual stacking. Think: Corporate offices. Rather than renumbering everything inside, they just turn on NAT64 and now they can begin a slow and controlled transition. On 9/26/18 2:19 PM, JORDI PALET MARTINEZ wrote: > You can use Jool for both 464XLAT and just NAT64. > > I've done a workshop on this at the LACNIC meeting this week. See slides 43 and next ones: > > http://www.lacnic.net/innovaportal/file/3139/1/ipv6-only_v11_16-9.pdf > > Saludos, > Jordi > > > > -----Mensaje original----- > De: NANOG en nombre de Matt Hoppes > Fecha: miércoles, 26 de septiembre de 2018, 15:03 > Para: North American Network Operators' Group > Asunto: Deploying IPv6 XLAT64 > > Looking at getting into IPv6 here ourselves... one of the big hold ups > has been the dual stacking. > > Can anyone recommend a quality, not ridiculously convoluted to setup, > XLAT64 translator that we could run in our network to take the IPv6 to > an IPv4 address when the remote server doesn't have 6 capability? > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From valdis.kletnieks at vt.edu Wed Sep 26 18:44:20 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 26 Sep 2018 14:44:20 -0400 Subject: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1) In-Reply-To: References: Message-ID: <73178.1537987460@turing-police.cc.vt.edu> On Wed, 26 Sep 2018 10:52:07 +0300, Michael Bullut said: > Has anyone deployed the aforementioned in your individual networks? A quick > test suggests it is quite fast compared with Google's D.N.S. resolvers: > *Reply from 1.1.1.1 : bytes=32 time=3ms TTL=61* 3ms indicates you're hitting an instance that is fairly close by, network-wise. Looking at your traceroute: 3     7 ms    13 ms    15 ms  10.98.0.233 4     7 ms     5 ms     4 ms  one.one.one.one [1.1.1.1] The instance is apparently on the same subnet as your CGN exit point. As such, unless CloudFlare is deploying a *lot* of anycast instances, most people are not going to have the joyous experience you have. >From my desktop, 1.1.1.1 is 7 network hops away, compared to 8.8.8.8's 10 hops, but the extra 3 hops inside AS15169 probably don't leave the building, and may not even leave the rack. Both are right around 6.9ms away - while *our* network presence there is 4 hops and also 6.9ms away and traceroute is showing jitter larger than the difference between our router and either DNS service... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From blake at ispn.net Wed Sep 26 18:59:20 2018 From: blake at ispn.net (Blake Hudson) Date: Wed, 26 Sep 2018 13:59:20 -0500 Subject: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1) In-Reply-To: <73178.1537987460@turing-police.cc.vt.edu> References: <73178.1537987460@turing-police.cc.vt.edu> Message-ID: valdis.kletnieks at vt.edu wrote on 9/26/2018 1:44 PM: > On Wed, 26 Sep 2018 10:52:07 +0300, Michael Bullut said: > >> Has anyone deployed the aforementioned in your individual networks? A quick >> test suggests it is quite fast compared with Google's D.N.S. resolvers: >> *Reply from 1.1.1.1 : bytes=32 time=3ms TTL=61* > 3ms indicates you're hitting an instance that is fairly close by, network-wise. > > Looking at your traceroute: > > 3     7 ms    13 ms    15 ms  10.98.0.233 > 4     7 ms     5 ms     4 ms  one.one.one.one [1.1.1.1] > > The instance is apparently on the same subnet as your CGN exit point. As such, > unless CloudFlare is deploying a *lot* of anycast instances, most people are > not going to have the joyous experience you have. > > From my desktop, 1.1.1.1 is 7 network hops away, compared to 8.8.8.8's 10 hops, > but the extra 3 hops inside AS15169 probably don't leave the building, and may > not even leave the rack. Both are right around 6.9ms away - while *our* network > presence there is 4 hops and also 6.9ms away and traceroute is showing jitter > larger than the difference between our router and either DNS service... > I'm not a proponent of using 1.1.1.1, but CloudFlare does have a good CDN: Pinging 1.1.1.1 with 32 bytes of data: Reply from 1.1.1.1: bytes=32 time<1ms TTL=58 Reply from 1.1.1.1: bytes=32 time<1ms TTL=58 Reply from 1.1.1.1: bytes=32 time<1ms TTL=58 Reply from 1.1.1.1: bytes=32 time<1ms TTL=58 Tracing route to one.one.one.one [1.1.1.1] over a maximum of 30 hops:   1    <1 ms    <1 ms    <1 ms  xxxx   2    <1 ms    <1 ms    <1 ms  xxxx   3    <1 ms    <1 ms    <1 ms xxxx   4     1 ms     1 ms     1 ms  209.152.151.8   5     1 ms     1 ms     1 ms  38.140.136.177   6     1 ms    <1 ms    <1 ms  38.140.136.74   7    <1 ms    <1 ms    <1 ms  one.one.one.one [1.1.1.1] Trace complete. dig @1.1.1.1 cloudflare.com | grep 'Query time' ;; Query time: 1 msec dig @1.1.1.1 nanog.org | grep 'Query time' ;; Query time: 28 msec From baldur.norddahl at gmail.com Wed Sep 26 19:58:23 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 26 Sep 2018 21:58:23 +0200 Subject: ARIN RPKI TAL deployment issues In-Reply-To: <52F2D40A-B3AA-4732-BDF0-E1C6250C8F48@arin.net> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <64F850AE-DD40-4D47-A006-EC152132CBDC@arin.net> <20180926122109.GR77517@vurt.meerval.net> <52F2D40A-B3AA-4732-BDF0-E1C6250C8F48@arin.net> Message-ID: ons. 26. sep. 2018 14.57 skrev John Curran : > In the case of ARIN, this does necessitate indemnification in order to > reduce risk exposure to the overall RIR mission. > > Thanks, > /John > > John Curran > President and CEO > ARIN > > Did you buy insurance? It is impossible to be immune from legal abuse. I did not agree to anything, yet might still use the service. If I am unhappy I might sue in a danish court of law, were the maner I got access to the service might or might not matter at all. This seems silly. Please find a way to make RPKI useful also in the ARIN region. Where there is will there is a way. Regards Baldur > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Wed Sep 26 20:26:58 2018 From: jcurran at arin.net (John Curran) Date: Wed, 26 Sep 2018 20:26:58 +0000 Subject: ARIN RPKI TAL deployment issues In-Reply-To: References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <64F850AE-DD40-4D47-A006-EC152132CBDC@arin.net> <20180926122109.GR77517@vurt.meerval.net> <52F2D40A-B3AA-4732-BDF0-E1C6250C8F48@arin.net> Message-ID: <51EB86BF-9374-48D8-8ADC-C769A120DBFC@arin.net> On Sep 26, 2018, at 3:58 PM, Baldur Norddahl > wrote: This seems silly. Please find a way to make RPKI useful also in the ARIN region. Baldur - RPKI in the ARIN region is useable (by definition, as there are indeed people in the region using it.) The question is whether to _improve_ its usability / accessibility, and the tradeoffs involved in doing so. While you may find some of those present tradeoffs “silly”, they have real legal basis and thus cannot be simply discarded but must be carefully considered. (As noted earlier on this thread, there is such an analysis going on presently and we’ll hear about its findings in a session at NANOG this coming Monday.) Thanks, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlm at pixelgate.net Wed Sep 26 21:18:43 2018 From: mlm at pixelgate.net (Mark Milhollan) Date: Wed, 26 Sep 2018 14:18:43 -0700 (PDT) Subject: ARIN RPKI TAL deployment issues In-Reply-To: <20180925210426.GO77517@vurt.meerval.net> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <20180925210426.GO77517@vurt.meerval.net> Message-ID: On Tue, 25 Sep 2018, Job Snijders wrote: >We really need to bring it back down to "apt install rpki-cache-validator" You say this as if no packager has a way to display and perhaps require approval of the license nor any way to fetch something remote as part of the installation process, e.g., the Microsoft "freely" supplied TTF files ... # zypper install fetchmsttfonts [...packager stuff...] (1/1) Installing: fetchmsttfonts-11.4-42.28.noarch .........................................[done] Running: fetchmsttfonts-11.4-42.28-fetchmsttfonts.sh.txt (fetchmsttfonts, /var/adm/update-scripts) EULA: END-USER LICENSE AGREEMENT FOR MICROSOFT SOFTWARE IMPORTANT-READ CAREFULLY: This Microsoft End-User License Agreement ("EULA") is a legal agreement between you (either an individual or a single entity) and [...] andale32.exe (https://sourceforge.net/projects/corefonts/files/the%20fonts/final/andale32.exe): Fetching ... done Extracting ... done [...] I bet apt, dnf, pacman, pkg_add, yum, etc., do as well -- actually I know some of those do. Perhaps fetching as part of installing is less desireable than already present at the outset, but it might appease ARIN and be workable (or superior) for many. /mark From nusenu-lists at riseup.net Wed Sep 26 21:29:00 2018 From: nusenu-lists at riseup.net (nusenu) Date: Wed, 26 Sep 2018 21:29:00 +0000 Subject: US based networks suffering from RPKI misconfigurations Message-ID: Hi, the tables bellow show the number of IPv4 and IPv6 blocks per ASN that are unreachable in an RPKI route origin validating (ROV) environment (this list is filtered for US ASNs based on RIPEstat ASN data). Affected networks might soon (by the end of the year) loose the ability to talk to Cloudflare networks since they plan to deploy ROV. You can use the RPKI validator https://rpki-validator.ripe.net/bgp-preview or https://bgp.he.net (prefix view) to find the specific affected prefixes for a given ASN. Apparently there are many using RIPE IP space, so: The RIPE RPKI dashboard offers a notification service for these kinds of problems and every operator should use it to get automatic alerts and avoid reduced reachability. https://www.ripe.net/manage-ips-and-asns/resource-management/certification/resource-certification-roa-management If the invalids are expected (i.e. to test ROV) than you can ignore this email (and maybe drop me an email). some more context: https://medium.com/@nusenu/where-are-rpki-unreachable-networks-located-65c7a0bae0f8 kind regards, nusenu amount of RPKI INVALID and unreachable /24 blocks per ASN in US: (data as of 2018-09-26 19:42 UTC) +----------+----------------------------------------------------------------+------------------------+ | ASN | AS Name | unreachable /24 blocks | +----------+----------------------------------------------------------------+------------------------+ | AS200983 | ABC-HOSTERS-LLC - ABC-HOSTERS LLC | 39 | | AS6364 | ATLANTIC-NET-1 - Atlantic.net | 30 | | AS20473 | AS-CHOOPA - Choopa | 27 | | AS36351 | SOFTLAYER - SoftLayer Technologies Inc. | 26 | | AS63267 | FAYETTEVILLEPUBLICUTILITIES-TN - Fayetteville Public Utilities | 16 | | AS21769 | AS-COLOAM - Colocation America Corporation | 13 | | AS14935 | MONTICELLO - Monticello Networks | 13 | | AS395378 | CASCADEDIVIDE-DC - Cascade Divide Colo | 11 | | AS6165 | UPTILT-ASN - Lyris Technology Inc. | 11 | | AS40676 | AS40676 - Psychz Networks | 10 | | AS10753 | LVLT-10753 - Level 3 Parent | 9 | | AS32181 | ASN-GIGENET - GigeNET | 9 | | AS54825 | PACKET - Packet Host | 7 | | AS36352 | AS-COLOCROSSING - ColoCrossing | 7 | | AS55079 | STELLANET - Third Gear Networks | 7 | | AS8100 | ASN-QUADRANET-GLOBAL - QuadraNet Enterprises LLC | 7 | | AS17216 | DC74-AS - DC74 LLC | 5 | | AS53429 | FREEDOMVOICE - FreedomVOICE Systems | 5 | | AS395970 | IONSWITCH - IonSwitch | 5 | | AS53889 | MICFO - Micfo | 4 | | AS29757 | WEBLINE19 - Webline Services Inc | 4 | | AS3549 | LVLT-3549 - Level 3 Parent | 4 | | AS19437 | SS-ASH - SECURED SERVERS LLC | 4 | | AS15003 | NOBIS-TECH - Nobis Technology Group | 4 | | AS46573 | GLOBAL-FRAG-NETWORKS - Global Frag Networks | 4 | | AS63018 | USDEDICATED - US Dedicated | 4 | | AS10991 | CAPGE-HOSTING-MRO - Capgemini U.S. LLC | 3 | | AS396194 | WISEDFW - WISE ISP | 3 | | AS20454 | SSASN2 - SECURED SERVERS LLC | 2 | | AS62541 | VSH-ASN - Vishay Intertechnology | 2 | | AS46186 | GILD-SCI - Gilead Sciences | 2 | | AS26938 | COMPUSOURCE - CompuSOURCE Communications Corp. | 2 | | AS33060 | SFPCU-AS-SF-POLICE-CREDIT-UNION - SFPCU | 2 | | AS11492 | CABLEONE - CABLE ONE | 1 | | AS13428 | SURFAIRWIRELESS-IN-02 - Surf Air Wireless | 1 | | AS393398 | ASN-DIS - Dallas Infrastructure Services | 1 | | AS6453 | AS6453 - TATA COMMUNICATIONS (AMERICA) INC | 1 | | AS5 | SYMBOLICS - Symbolics | 1 | | AS30542 | MOVI-R-TECH-SOLUTIONS - MOVI-R | 1 | | AS32780 | HOSTINGSERVICES-INC - Hosting Services | 1 | | AS30167 | XCNETWORKS-30167 - XC Networks | 1 | | AS46636 | NATCOWEB - NatCoWeb Corp. | 1 | | AS55097 | MICROOFFICE - Micro Office Solutions | 1 | | AS26827 | EPBTELECOM - EPB Fiber Optics | 1 | | AS17090 | DATABASEBYDESIGNLLC - Database by Design | 1 | | AS395734 | YLINX - YLINX | 1 | | AS40244 | TURNKEY-INTERNET - Turnkey Internet Inc. | 1 | | AS17139 | NETRANGE - Corporate Colocation Inc. | 1 | | AS1280 | ISC-AS-1280 - Internet Systems Consortium | 1 | | AS31863 | DACEN-2 - Centrilogic | 1 | | AS29854 | WESTHOST - WestHost | 1 | | AS54500 | 18779 - EGIHosting | 1 | | AS393451 | ONLIGHTAURORA - On Light Aurora | 1 | | AS14237 | BEAMSPEED1 - Beamspeed LLC | 1 | | AS29713 | ELIA-60 - Reliable Hosting Services | 1 | +----------+----------------------------------------------------------------+------------------------+ for IPv6: +----------+--------------------------------------------------------------------+------------------------+ | ASN | AS Name | unreachable /24 blocks | +----------+--------------------------------------------------------------------+------------------------+ | AS200775 | DATAPROM-LLC - Joao Carlos de Almeida Silveira trading as Bitcanal | 524288 | "Bitcanal" ;) | AS36351 | SOFTLAYER - SoftLayer Technologies Inc. | 4096 | | AS394497 | TF-178-ASH - Ting Fiber Inc. | 4 | | AS55079 | STELLANET - Third Gear Networks | 3 | | AS46407 | AS-CHOOPA3 - Choopa | 2 | | AS55097 | MICROOFFICE - Micro Office Solutions | 1 | | AS394644 | TF-178-ASH1 - Ting Fiber Inc. | 1 | | AS60188 | HOSTKER-LLC - Hostker LLC | 1 | | AS3549 | LVLT-3549 - Level 3 Parent | 1 | | AS394308 | TING-FIBER - Ting Fiber Inc. | 1 | | AS46573 | GLOBAL-FRAG-NETWORKS - Global Frag Networks | 1 | +----------+--------------------------------------------------------------------+------------------------+ -- https://twitter.com/nusenu_ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From jbothe at me.com Wed Sep 26 21:57:03 2018 From: jbothe at me.com (JASON BOTHE) Date: Wed, 26 Sep 2018 16:57:03 -0500 Subject: Rogers AS812 help Message-ID: <29C06D8D-6C7B-4B70-B863-B67E61FA4BA1@me.com> Hi NOGers If anyone from Rogers is on, could you please contact me offline? Thanks J~ From randy at psg.com Thu Sep 27 00:14:36 2018 From: randy at psg.com (Randy Bush) Date: Wed, 26 Sep 2018 17:14:36 -0700 Subject: US based networks suffering from RPKI misconfigurations In-Reply-To: References: Message-ID: > Affected networks might soon (by the end of the year) loose the > ability to talk to Cloudflare networks since they plan to deploy ROV. and then they will clean up their messes until then you can generate a lot of email if it amuses you randy From marka at isc.org Thu Sep 27 00:20:14 2018 From: marka at isc.org (Mark Andrews) Date: Thu, 27 Sep 2018 10:20:14 +1000 Subject: Deploying IPv6 XLAT64 In-Reply-To: References: <20ae0d18-88cc-03f9-207d-856a8564fa14@rivervalleyinternet.net> Message-ID: > On 27 Sep 2018, at 4:22 am, Matt Hoppes wrote: > > Thanks... that is what I don't understand: Why is NAT64 such a difficult concept to put into routers and firewalls? We already do NAT with IPv4 just fine. It’s not s difficult concept but you need to remember NAT44 breaks stuff and NAT64/NAT46 breaks more stuff. > I feel like IPv6 adoption would be much faster if there was a transition mechanism other than dual stacking. Dual stacking is SIMPLE. REALLY. Turn on IPv6 with the M bit set and configure the DHCPv6 server. If you don’t need that level of control of address assignments leave the M bit off. 99.99% of your machines will just add a second address to the interface without you having to do anything more. > Think: Corporate offices. Rather than renumbering everything inside, they just turn on NAT64 and now they can begin a slow and controlled transition. Getting to IPv6 resources from IPv4 address is a *much* harder problem that getting to IPv4 resources from IPv6 which is what you are describing here with the “no renumber everything as they already have a IPv4 address” requirement. NAT64 allows IPv6 devices to get to legacy IPv4 servers. To allow IPv4 devices to get to IPv6 servers you need to map the IPv6 addresses you want to talk to in to a pool of IPv4 addresses and push that mapping to a NAT46 (not NAT64) device. Go dual stack then, once IPv6 is stable, turn off IPv4 if you want to be single stacked. You are then no longer dependent on the services you want want to access continuing to be offered over IPv4. 464XLAT will only work as a stop gap for IPv4 clients while services are offered over IPv4. After ~20 years of IPv6 being available (Windows XP had IPv6 support and it was not the first major OS to have it) just turn on IPv6. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jcurran at arin.net Thu Sep 27 11:04:36 2018 From: jcurran at arin.net (John Curran) Date: Thu, 27 Sep 2018 11:04:36 +0000 Subject: ARIN RPKI TAL deployment issues In-Reply-To: References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <20180925210426.GO77517@vurt.meerval.net> Message-ID: On 26 Sep 2018, at 5:18 PM, Mark Milhollan wrote: > On Tue, 25 Sep 2018, Job Snijders wrote: > >> We really need to bring it back down to "apt install rpki-cache-validator" > > You say this as if no packager has a way to display and perhaps require > approval of the license nor any way to fetch something remote as part of > the installation process, e.g., the Microsoft "freely" supplied TTF > files … > ... > I bet apt, dnf, pacman, pkg_add, yum, etc., do as well -- actually I > know some of those do. Perhaps fetching as part of installing is less > desireable than already present at the outset, but it might appease ARIN > and be workable (or superior) for many. Mark - Agreed: operationally it should be relatively straightforward with most installation tools, but ARIN could help significantly be making it clear this sort of approach is acceptable with its service terms and detailing any specific requirements (as none of that is clear at present.) I’m working on this issue now, and should be able to report back shortly regarding specifics necessary to allow easier access to the ARIN TAL during package installation. Thanks! /John John Curran President and CEO ARIN From theghost101 at gmail.com Thu Sep 27 12:30:58 2018 From: theghost101 at gmail.com (Danijel Starman) Date: Thu, 27 Sep 2018 14:30:58 +0200 Subject: Massive Price Increase for X-conns at Telehouse Chelsea, NYC In-Reply-To: References: Message-ID: On Mon, Sep 17, 2018 at 4:59 PM Fredy Kuenzler wrote: > Is anyone else affected by a massive price increase for x-conns by > Telehouse Chelsea? > If I recall correctly in just switching to 100G ports instead of multiple 10G bundles we managed to pay off new switches in ~6 months. (not on that specific location but prices are high). -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at imaginenetworksllc.com Thu Sep 27 14:10:17 2018 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 27 Sep 2018 10:10:17 -0400 Subject: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1) In-Reply-To: <16C1594D-E662-4805-B3BD-67A70811D36E@gmail.com> References: <16C1594D-E662-4805-B3BD-67A70811D36E@gmail.com> Message-ID: +1 for Yoni's recommendation of DNS Benchmark (Windows only). Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Sep 26, 2018 at 9:03 AM, Yoni Radzin wrote: > > For Window’s clients, you might want to try out this freeware GRC tool for > benchmarking DNS performance: > > https://www.grc.com/dns/benchmark.htm > > Cheers > > -- > *Yonatan (Yoni) Radzin* > *yradzin at gmail.com * > > On Sep 26, 2018, at 3:59 AM, Michael Bullut
wrote: > > Hi Ross, > > How would you gauge good DNS performance? > > Warm regards, > > Michael. > > > On Wed, 26 Sep 2018 at 10:50, Ross Tajvar wrote: > >> Do note that ping response times are not a good indicator of DNS >> performance. >> >> On Wed, Sep 26, 2018, 3:48 AM Michael Bullut
wrote: >> >>> Greetings Team, >>> >>> Has anyone deployed the aforementioned in your individual networks? A >>> quick test suggests it is quite fast compared with Google's D.N.S. >>> resolvers: >>> >>> *C:\Users\bullutm>ping 1.1.1.1* >>> >>> *Pinging 1.1.1.1 with 32 bytes of data:* >>> *Reply from 1.1.1.1 : bytes=32 time=3ms TTL=61* >>> *Reply from 1.1.1.1 : bytes=32 time=4ms TTL=61* >>> *Reply from 1.1.1.1 : bytes=32 time=8ms TTL=61* >>> *Reply from 1.1.1.1 : bytes=32 time=4ms TTL=61* >>> >>> *Ping statistics for 1.1.1.1 :* >>> * Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),* >>> *Approximate round trip times in milli-seconds:* >>> * Minimum = 3ms, Maximum = 8ms, Average = 4ms* >>> >>> *C:\Users\bullutm>* >>> >>> *-------* >>> >>> *C:\Users\bullutm>tracert 1.1.1.1* >>> >>> *Tracing route to one.one.one.one [1.1.1.1]* >>> *over a maximum of 30 hops:* >>> >>> * 1 4 ms >>> 3 ms >>> 4 ms >>> 10.101.129.254* >>> * 2 6 ms >>> 20 ms >>> 7 >>> ms >>> 10.98.0.165* >>> * 3 7 ms 13 ms >>> 15 ms >>> 10.98.0.233* >>> * 4 7 ms 5 ms 4 ms one.one.one.one [1.1.1.1]* >>> >>> *Trace complete.* >>> >>> *C:\Users\bullutm>* >>> >>> Warm regards, >>> >>> Michael Bullut. >>> >>> --- >>> >>> *Cell:* >>> *+254 723 393 114.**Skype Name:* *Michael Bullut.* >>> *Twitter:* >>> * @Kipsang * >>> *Blog: http://www.kipsang.com/ * >>> *E-mail:* *main at kipsang.com
* >>> >>> *---* >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Thu Sep 27 16:31:50 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 27 Sep 2018 10:31:50 -0600 Subject: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1) In-Reply-To: References: <16C1594D-E662-4805-B3BD-67A70811D36E@gmail.com> Message-ID: On 09/27/2018 08:10 AM, Josh Luthman wrote: > +1 for Yoni's recommendation of DNS Benchmark (Windows only). I've heard of multiple people running Steve's free DNS Benchmark utility on Mac OS X and Linux via Wine. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From ciscofreak at outlook.com Fri Sep 28 01:37:42 2018 From: ciscofreak at outlook.com (Hari .) Date: Fri, 28 Sep 2018 01:37:42 +0000 Subject: l2tpv3 Issue on 6800 Message-ID: Hello Team, We are trying to extend the L2doamin for IP cloud (Non MPLS), the intention was to use l2tpv3, but it doesn't seem to be supported in 6800/3850.. Anyone tried or can provide some guidance.. Ta, -------------- next part -------------- An HTML attachment was scrubbed... URL: From EPers at ansencorp.com Fri Sep 28 15:07:21 2018 From: EPers at ansencorp.com (Edwin Pers) Date: Fri, 28 Sep 2018 15:07:21 +0000 Subject: l2tpv3 Issue on 6800 In-Reply-To: References: Message-ID: Unicast vxlan maybe? -ed From: NANOG On Behalf Of Hari . Sent: Thursday, September 27, 2018 9:38 PM To: nanog at nanog.org Subject: l2tpv3 Issue on 6800 Hello Team, We are trying to extend the L2doamin for IP cloud (Non MPLS), the intention was to use l2tpv3, but it doesn't seem to be supported in 6800/3850.. Anyone tried or can provide some guidance.. Ta, -------------- next part -------------- An HTML attachment was scrubbed... URL: From cscora at apnic.net Fri Sep 28 18:03:12 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 29 Sep 2018 04:03:12 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180928180312.B448BC450F@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 29 Sep, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 718431 Prefixes after maximum aggregation (per Origin AS): 276135 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 344920 Total ASes present in the Internet Routing Table: 61949 Prefixes per ASN: 11.60 Origin-only ASes present in the Internet Routing Table: 53479 Origin ASes announcing only one prefix: 23303 Transit ASes present in the Internet Routing Table: 8470 Transit-only ASes present in the Internet Routing Table: 258 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 36 Max AS path prepend of ASN ( 30873) 34 Prefixes from unregistered ASNs in the Routing Table: 47 Number of instances of unregistered ASNs: 47 Number of 32-bit ASNs allocated by the RIRs: 24227 Number of 32-bit ASNs visible in the Routing Table: 19553 Prefixes from 32-bit ASNs in the Routing Table: 82433 Number of bogon 32-bit ASNs visible in the Routing Table: 13 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 297 Number of addresses announced to Internet: 2854737091 Equivalent to 170 /8s, 39 /16s and 212 /24s Percentage of available address space announced: 77.1 Percentage of allocated address space announced: 77.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.0 Total number of prefixes smaller than registry allocations: 240210 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 195396 Total APNIC prefixes after maximum aggregation: 55713 APNIC Deaggregation factor: 3.51 Prefixes being announced from the APNIC address blocks: 193250 Unique aggregates announced from the APNIC address blocks: 79704 APNIC Region origin ASes present in the Internet Routing Table: 9114 APNIC Prefixes per ASN: 21.20 APNIC Region origin ASes announcing only one prefix: 2559 APNIC Region transit ASes present in the Internet Routing Table: 1363 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 30 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4078 Number of APNIC addresses announced to Internet: 767593602 Equivalent to 45 /8s, 192 /16s and 140 /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: 214048 Total ARIN prefixes after maximum aggregation: 101265 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 213746 Unique aggregates announced from the ARIN address blocks: 101660 ARIN Region origin ASes present in the Internet Routing Table: 18250 ARIN Prefixes per ASN: 11.71 ARIN Region origin ASes announcing only one prefix: 6772 ARIN Region transit ASes present in the Internet Routing Table: 1810 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2441 Number of ARIN addresses announced to Internet: 1098335136 Equivalent to 65 /8s, 119 /16s and 67 /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: 196161 Total RIPE prefixes after maximum aggregation: 93683 RIPE Deaggregation factor: 2.09 Prefixes being announced from the RIPE address blocks: 192448 Unique aggregates announced from the RIPE address blocks: 113867 RIPE Region origin ASes present in the Internet Routing Table: 25510 RIPE Prefixes per ASN: 7.54 RIPE Region origin ASes announcing only one prefix: 11484 RIPE Region transit ASes present in the Internet Routing Table: 3525 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 36 Number of RIPE region 32-bit ASNs visible in the Routing Table: 7425 Number of RIPE addresses announced to Internet: 714730112 Equivalent to 42 /8s, 153 /16s and 234 /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: 93175 Total LACNIC prefixes after maximum aggregation: 21264 LACNIC Deaggregation factor: 4.38 Prefixes being announced from the LACNIC address blocks: 94556 Unique aggregates announced from the LACNIC address blocks: 41268 LACNIC Region origin ASes present in the Internet Routing Table: 7590 LACNIC Prefixes per ASN: 12.46 LACNIC Region origin ASes announcing only one prefix: 2081 LACNIC Region transit ASes present in the Internet Routing Table: 1430 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 24 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 5136 Number of LACNIC addresses announced to Internet: 172160544 Equivalent to 10 /8s, 66 /16s and 246 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 19603 Total AfriNIC prefixes after maximum aggregation: 4168 AfriNIC Deaggregation factor: 4.70 Prefixes being announced from the AfriNIC address blocks: 24134 Unique aggregates announced from the AfriNIC address blocks: 8164 AfriNIC Region origin ASes present in the Internet Routing Table: 1202 AfriNIC Prefixes per ASN: 20.08 AfriNIC Region origin ASes announcing only one prefix: 407 AfriNIC Region transit ASes present in the Internet Routing Table: 244 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 29 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 473 Number of AfriNIC addresses announced to Internet: 101476864 Equivalent to 6 /8s, 12 /16s and 106 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 4632 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4448 485 476 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 2981 1153 92 VIETEL-AS-AP Viettel Group, VN 4766 2822 11130 764 KIXS-AS-KR Korea Telecom, KR 9829 2807 1495 540 BSNL-NIB National Internet Backbone, IN 45899 2755 1666 158 VNPT-AS-VN VNPT Corp, VN 9394 2589 4907 31 CTTNET China TieTong Telecommunications 9808 2269 8699 26 CMNET-GD Guangdong Mobile Communication 17974 2251 972 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4755 2126 417 203 TATACOMM-AS TATA Communications formerl Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 11492 3554 233 463 CABLEONE - CABLE ONE, INC., US 6327 3466 1324 83 SHAW - Shaw Communications Inc., CA 22773 3239 2971 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2303 5003 804 AMAZON-02 - Amazon.com, Inc., US 18566 2160 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2155 2741 519 CHARTER-NET-HKY-NC - Charter Communicat 5650 2082 3074 1461 FRONTIER-FRTR - Frontier Communications 16625 2056 1094 1530 AKAMAI-AS - Akamai Technologies, Inc., 30036 2051 347 130 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 2038 5081 598 CENTURYLINK-US-LEGACY-QWEST - Qwest Com Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 4902 1616 127 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3056 378 51 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2560 592 1911 AKAMAI-ASN1, US 12389 2093 2039 676 ROSTELECOM-AS, RU 34984 2044 337 507 TELLCOM-AS, TR 9121 1978 1691 17 TTNET, TR 13188 1602 100 46 TRIOLAN, UA 8402 1245 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1241 355 21 UKRTELNET, UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5438 3307 605 Uninet S.A. de C.V., MX 10620 3195 489 804 Telmex Colombia S.A., CO 11830 2655 370 81 Instituto Costarricense de Electricidad 6503 1654 444 66 Axtel, S.A.B. de C.V., MX 7303 1432 955 206 Telecom Argentina S.A., AR 28573 1102 2231 193 CLARO S.A., BR 3816 1014 509 121 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 963 377 31 Telefonica del Peru S.A.A., PE 11172 934 144 71 Alestra, S. de R.L. de C.V., MX 18881 919 1114 28 TELEF�NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1207 396 48 LINKdotNET-AS, EG 37611 904 107 9 Afrihost, ZA 36903 797 400 139 MT-MPLS, MA 36992 747 1411 41 ETISALAT-MISR, EG 24835 653 802 18 RAYA-AS, EG 8452 594 1728 15 TE-AS TE-AS, EG 37492 464 470 55 ORANGE-, TN 29571 463 70 11 ORANGE-COTE-IVOIRE, CI 37342 394 32 1 MOVITEL, MZ 23889 381 231 15 MauritiusTelecom, MU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 5438 3307 605 Uninet S.A. de C.V., MX 12479 4902 1616 127 UNI2-AS, ES 4538 4632 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4448 485 476 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 11492 3554 233 463 CABLEONE - CABLE ONE, INC., US 6327 3466 1324 83 SHAW - Shaw Communications Inc., CA 22773 3239 2971 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3195 489 804 Telmex Colombia S.A., CO 8551 3056 378 51 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 4902 4775 UNI2-AS, ES 4538 4632 4558 ERX-CERNET-BKB China Education and Research Net 7545 4448 3972 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3466 3383 SHAW - Shaw Communications Inc., CA 11492 3554 3091 CABLEONE - CABLE ONE, INC., US 22773 3239 3083 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3056 3005 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 2981 2889 VIETEL-AS-AP Viettel Group, VN 45899 2755 2597 VNPT-AS-VN VNPT Corp, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 64500 DOCUMENT 45.43.56.0/24 45474 NEXUSGUARD-AS-AP Suite 2101~02 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 64121 UNALLOCATED 98.159.9.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64121 UNALLOCATED 98.159.12.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64140 UNALLOCATED 98.159.14.0/24 64121 UNKNOWN 65001 PRIVATE 109.161.56.0/24 13118 ASN-YARTELECOM PJSC Rostelecom 64643 PRIVATE 119.44.18.0/24 9394 CTTNET China TieTong Telecommu Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 198.18.1.19/32 7497 CSTNET-AS-AP Computer Network Information Cente Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 45.121.32.0/22 134356 UNKNOWN 45.121.136.0/22 22552 ESITED - eSited Solutions, US 45.124.164.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU 45.252.236.0/22 38803 GTELECOM-AUSTRALIA Gtelecom-AUSTRALIA, AU 64.28.160.0/20 20475 AS20475 - Global Capacity, LLC, US 64.29.240.0/20 27279 -Reserved AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:14 /9:11 /10:36 /11:98 /12:289 /13:566 /14:1102 /15:1885 /16:13329 /17:7897 /18:13795 /19:25335 /20:39509 /21:45936 /22:89200 /23:73246 /24:403985 /25:816 /26:618 /27:628 /28:38 /29:21 /30:21 /31:4 /32:52 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 3667 4902 UNI2-AS, ES 6327 3252 3466 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2806 3554 CABLEONE - CABLE ONE, INC., US 8551 2512 3056 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2501 3239 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2054 2160 MEGAPATH5-US - MegaPath Corporation, US 11830 2005 2655 Instituto Costarricense de Electricidad y Telec 30036 1799 2051 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 5650 1762 2082 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:1599 2:842 4:18 5:2628 6:42 7:1 8:1131 12:1867 13:211 14:1817 15:33 16:3 17:196 18:55 20:50 23:2495 24:2417 25:2 27:2501 31:1988 32:88 35:29 36:536 37:2847 38:1538 39:261 40:121 41:3168 42:709 43:1946 44:120 45:5631 46:3101 47:216 49:1347 50:1057 51:318 52:1086 54:367 55:2 56:12 57:41 58:1625 59:989 60:417 61:2087 62:1895 63:1797 64:5042 65:2210 66:4827 67:2668 68:1153 69:3365 70:1156 71:576 72:2262 74:2723 75:418 76:457 77:1640 78:1709 79:2235 80:1567 81:1403 82:1061 83:789 84:1046 85:2036 86:560 87:1446 88:954 89:2344 90:207 91:6443 92:1297 93:2395 94:2441 95:3050 96:931 97:353 98:927 99:140 100:86 101:1190 102:233 103:18697 104:3535 105:218 106:769 107:1806 108:707 109:3360 110:1656 111:1811 112:1333 113:1307 114:1129 115:1674 116:1666 117:1791 118:2208 119:1671 120:1081 121:1047 122:2377 123:1644 124:1440 125:1932 128:1178 129:690 130:498 131:1608 132:726 133:191 134:1032 135:236 136:514 137:663 138:1938 139:686 140:548 141:757 142:845 143:1015 144:823 145:496 146:1242 147:737 148:1680 149:769 150:764 151:988 152:862 153:323 154:1859 155:916 156:1472 157:809 158:658 159:1870 160:1470 161:843 162:2663 163:617 164:1089 165:1559 166:454 167:1258 168:3154 169:854 170:3975 171:497 172:1001 173:2089 174:1000 175:806 176:2089 177:4025 178:2517 179:1318 180:2145 181:2440 182:2371 183:1275 184:1135 185:14117 186:3590 187:2531 188:2910 189:2028 190:8182 191:1397 192:9861 193:6276 194:5065 195:4014 196:2778 197:1618 198:5665 199:5980 200:7359 201:4978 202:10231 203:10283 204:4608 205:3000 206:3219 207:3193 208:3935 209:4095 210:3861 211:1997 212:3026 213:2820 214:1044 215:54 216:6028 217:2156 218:864 219:569 220:1797 221:1000 222:983 223:1390 End of report From stu at spacehopper.org Thu Sep 27 11:12:33 2018 From: stu at spacehopper.org (Stuart Henderson) Date: Thu, 27 Sep 2018 11:12:33 +0000 (UTC) Subject: ARIN RPKI TAL deployment issues References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <20180925210426.GO77517@vurt.meerval.net> Message-ID: On 2018-09-26, Mark Milhollan wrote: > On Tue, 25 Sep 2018, Job Snijders wrote: > >>We really need to bring it back down to "apt install rpki-cache-validator" > > You say this as if no packager has a way to display and perhaps require > approval of the license nor any way to fetch something remote as part of > the installation process, e.g., the Microsoft "freely" supplied TTF > files ... > > # zypper install fetchmsttfonts > [...packager stuff...] > (1/1) Installing: fetchmsttfonts-11.4-42.28.noarch .........................................[done] > Running: fetchmsttfonts-11.4-42.28-fetchmsttfonts.sh.txt (fetchmsttfonts, /var/adm/update-scripts) > EULA: > END-USER LICENSE AGREEMENT FOR > MICROSOFT SOFTWARE > > IMPORTANT-READ CAREFULLY: This Microsoft End-User License Agreement ("EULA") is > a legal agreement between you (either an individual or a single entity) and > [...] > andale32.exe (https://sourceforge.net/projects/corefonts/files/the%20fonts/final/andale32.exe): > Fetching ... done > Extracting ... done > [...] > > I bet apt, dnf, pacman, pkg_add, yum, etc., do as well -- actually I > know some of those do. Some do, some don't. As far as OpenBSD is concerned, pkg_add will install signed packages distributed by OpenBSD, they can only do that if free redistribution is possible. For things like the Microsoft fonts, they can be installed, but by a different process which is a lot more work. There's a big difference between this and something like the Microsoft fonts in your example: the fonts are clearly creative work and copyrightable. A generated integer in an RFC-specified format? That seems less likely. From cra at wpi.edu Fri Sep 28 20:01:52 2018 From: cra at wpi.edu (Anderson, Charles R) Date: Fri, 28 Sep 2018 20:01:52 +0000 Subject: ARIN RPKI TAL deployment issues In-Reply-To: References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <20180925210426.GO77517@vurt.meerval.net> Message-ID: <20180928200149.vcaturtfo3mqy7zm@angus.ind.wpi.edu> On Wed, Sep 26, 2018 at 02:18:43PM -0700, Mark Milhollan wrote: > On Tue, 25 Sep 2018, Job Snijders wrote: > > >We really need to bring it back down to "apt install rpki-cache-validator" > > You say this as if no packager has a way to display and perhaps require > approval of the license nor any way to fetch something remote as part of > the installation process, e.g., the Microsoft "freely" supplied TTF > files ... > [...] > > I bet apt, dnf, pacman, pkg_add, yum, etc., do as well -- actually I > know some of those do. Perhaps fetching as part of installing is less > desireable than already present at the outset, but it might appease ARIN > and be workable (or superior) for many. rpm/yum/dnf do NOT have a way to allow the installation of packages to interact with the user. They specifically block this functionality since it goes against their design of allowing non-interactive installs. From nanog at ics-il.net Sat Sep 29 15:34:10 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 29 Sep 2018 10:34:10 -0500 (CDT) Subject: Lightcore In-Reply-To: <272955326.3756.1538235216988.JavaMail.mhammett@ThunderFuck> Message-ID: <1443308229.3761.1538235245984.JavaMail.mhammett@ThunderFuck> Is anyone in here familiar with the Centurylink\Lightcore\Digital Teleport\Level 3\Genuity\Midwest Fiber Optic Network\etc. route that started in DeKalb, IL and went west? I thought it went to every CO in towns just north of I-88. Archive.org is failing me for bringing up the network map they had on their web site. The rest of the flash on that page loads, just not the map. https://web.archive.org/web/20070226213123/http://www.lightcore.net:80/network_nm.php ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikm at cyberflunk.com Sat Sep 29 21:34:33 2018 From: nikm at cyberflunk.com (Nikos Mouat) Date: Sat, 29 Sep 2018 14:34:33 -0700 (PDT) Subject: Puerto Rico Internet Exchange Message-ID: Hi Mehmet - You mention the SIX so I figured I'd chime in on this thread, despite being an old one. We were in a similar situation in early 1997 - Seattle was a backwoods as far as internet infrastructure, with the nearest hub of activity being Mae-West / PAIX, and not a whole lot else in our neck of the woods. We had tried to build some momentum with a T1/Frame-relay based multi-point peering fabric which came online in early '96, but it never got past 5 or 6 participants and didn't get much traction with some providers in the region. We had talked about doing an ethernet based exchange in the Westin, and the University of Washington had started talking about building the SNNAP (Seattle Network to Network Access Point) which started up a mailing list in early '97, but it seemed to always be just over the horizon. (It eventually launched as the Pacific Northwest Gigapop, but not until much later, and focused on research and education orgs). When Chris and I were sitting together at Nanog 10, Bill Manning gave a couple presentations - "International Exchange Points: Growth & Trends" and "Large & Small Exchange Points: Advantages,Tradeoffs, Futures", and one of his key points was something along the lines of "any exchange point with 3 or more participants is a successful exchange point". This was ultimately the final nudge that was needed to convince us to start the peering point, and shortly after we got back from Tampa we threw a hub in on a port I was using for a private peering session and we were in business. We've grown a lot since then, certainly the emergence of Seattle as a key content market helped a lot, but I think you can draw some parallels. If you measure success as having three participants peering, and you find a way to get off the ground with minimal costs (or as in our case, none at all), it's easy to succeed in a not-for-profit model. My advice to you is to not worry about if any out of region folks are going to show up - find a space that folks operating in the region can get to easily, build something that is inexpensive to keep online, keep it simple, and get 3 participants. Once you're there - look for the 4th, and so on. Good luck, Nikos On Thu, 13 Sep 2018, Mehmet Akcin wrote: > It has been little over a year and we have been working on launching an > internet exchange in puerto rico but of course hurricane and other things > got in the way of achieving this. > > We now have identified what we believe the right location (most of the > isp’s have presence in this location) backbone/ip transit connectivity, > local team to provide onsite support. > > Having said that We have been engaged with several content delivery > networks, OTTs but general feedback was that Puerto Rico was not on their > radar for 2018 hence delayed launch. Now we are talking to same players > about 2019 but general answer seemed like people were satisfied enough to > serve Puerto Rico from Miami. > > Perhaps we are talking to really big CDNs, OTTs and we should engage > differently however the level of interest is very low and I really don’t > want to “build and they will come” again ;-) > > Bottom line is, if there was an IXP in Puerto Rico similar to ones in > Florida, I am trying to understand who would actually deploy (just speak to > your company only please) because most of my assumptions were proven wrong > ;-) > > I guess I want to ask two questions, given its location in caribbean, does > Puerto Rico need an internet exchange point? Would you join it?(it will be > a membership based IXP where members share cost) > > Mehmet > > On Sat, Aug 12, 2017 at 4:27 AM Mehmet Akcin wrote: > >> Hey there! >> >> ... ok this time I am not going to call it PRIX ;) well name doesn't >> matter really. Nearly 13 years ago I have attempted to start Puerto rico >> Internet exchange in San Juan. I have lived there over 5 years and i just >> wanted to really watch videos faster. The project somewhat died when i >> moved to LA but now there are few interested party to start an internet >> exchange in Puerto rico. The jsland historically had one of the slowest >> broadband/internet services which seemed to have improved in recent years >> however as of 2017 there still is not an IX in Puerto rico. >> >> We , 3-4 internet engineers (on island and remote) , want to look into >> relaunch of this IX and hopefully find a way to keep local traffic >> exchanged at high speeds and low cost. We need expertise, and people who >> want to help any way they can. >> >> We are trying to make this IX a not-for-profit one and we are looking at >> opeeating models to adapt which has worked incredibly well like Seattle IX. >> >> We are hoping the relaunch to happen sometime in 2018. Thanks in advance >> hope to share more info and traffic data sometime , soon. Watch this space! >> >> Mehmet >> > -- > Mehmet > +1-424-298-1903 > From maillists at krassi.biz Sat Sep 29 23:18:57 2018 From: maillists at krassi.biz (Krassimir Tzvetanov) Date: Sat, 29 Sep 2018 16:18:57 -0700 Subject: NANOG Security Track: Route Security In-Reply-To: References: Message-ID: Hello Everyone, I wanted to attract your attention to the Security Track this coming NANOG. We'll be meeting on Tuesday morning and the line up looks like this: * Andre Toonk - examples of hijacks, other ideas * Alexander Azimov - State of BGP Security * David Wishnick - ARIN TAL * Job Snijders - Routing security roadmap * Chris Morrow - So I need to start filtering routes from peers...' and 'hey guess who needs to update their IRR data?' Time permitting at the end of the time slot we'll have a panel and time for duscussion as well. Regards, Krassi -------------- next part -------------- An HTML attachment was scrubbed... URL: From sam.oduor at gmail.com Sun Sep 30 20:05:29 2018 From: sam.oduor at gmail.com (Sam Oduor) Date: Sun, 30 Sep 2018 23:05:29 +0300 Subject: NANOG Security Track: Route Security In-Reply-To: References: Message-ID: Hi Any online link available for remote participation or viewing ? On Sun, Sep 30, 2018 at 7:46 PM Krassimir Tzvetanov wrote: > Hello Everyone, > > I wanted to attract your attention to the Security Track this coming > NANOG. We'll be meeting on Tuesday morning and the line up looks like this: > * Andre Toonk - examples of hijacks, other ideas > * Alexander Azimov - State of BGP Security > * David Wishnick - ARIN TAL > * Job Snijders - Routing security roadmap > * Chris Morrow - So I need to start filtering routes from peers...' and > 'hey guess who needs to update their IRR data?' > > Time permitting at the end of the time slot we'll have a panel and time > for duscussion as well. > > Regards, > Krassi > > -- Samson Oduor -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Sun Sep 30 23:21:50 2018 From: jcurran at arin.net (John Curran) Date: Sun, 30 Sep 2018 23:21:50 +0000 Subject: Towards an RPKI-rich Internet (and the appropriate allocation of responsibility in the event an RIR RPKI CA outage) In-Reply-To: <20180928200149.vcaturtfo3mqy7zm@angus.ind.wpi.edu> References: <20180925173005.GL77517@vurt.meerval.net> <25E9438A-0C56-4D33-B7C4-7CF8E0AC0DE7@istaff.org> <20180925193451.GM77517@vurt.meerval.net> <565B4356-32B4-4499-BDE7-AF5D17D7363A@arin.net> <20180925210426.GO77517@vurt.meerval.net> <20180928200149.vcaturtfo3mqy7zm@angus.ind.wpi.edu> Message-ID: Folks - Perhaps it would be helpful to confirm that we have common goals in the network operator community regarding RPKI, and then work from those goals on the necessary plans to achieve them. It appears that many network operators would like to improve the integrity of their network routing via RPKI deployment. The Regional Internet Registries (RIRs) have all worked to support RPKI services, and while there are different opinions among operators regarding the cost/benefit tradeoffs of RPKI Route Origin Validation (ROV), it is clear that we have to collectively work together now if we are ever to have overall RPKI deployment sufficient to create the network effects that will ensure compelling long-term value for its deployment. Let’s presume that we’ve achieved that very outcome at some point in future; i.e. we’re have an Internet where nearly all network operators are publishing Route Origin Authorizations (ROAs) via RIR RPKI services and are using RPKI data for route validation. It is reasonable to presume that over the next decade the Internet will become even more pervasive in everyday life, including being essential for many connected devices to function, and relied upon for everything from daily personal communication and conducting business to even more innovative uses such as payment & sale systems, delivery of medical care, etc. Recognizing that purpose of RPKI is improve integrity of routing, and not add undo fragility to the network, it is reasonable to expect that many network operators will take due care with the introduction of route validation into their network routing, including best practices such as falling back successfully in the event of unavailability of an RIR RPKI Certificate Authority (CA) and resulting cache timeouts. It is also reasonable expect that RIR RPKI CA services are provisioned with appropriate robustness of systems and controls that befit the highly network-critical nature of these services. Presuming we all share this common goal, the question that arises is whether we have a common vision regarding what should happen when something goes wrong in this wonderful RPKI-rich Internet of the future… More than anyone, network operators realize that even with excellent systems, procedures, and redundancy, outages can (and do) still occur. Hopefully, these are quite rare, and limited to occasions where Murphy’s Law has somehow resulted in nearly unimaginable patterns of coincident failures, but it would irresponsible to not consider the “what if” scenarios for RPKI failure and whether there is shared vision of the resulting consequences. In particular, it would be good to consider the case of an RIR RPKI CA system failure, one sufficient to result in widespread cache expirations for relying parties. Ideally, we will never have to see this scenario when RPKI is widely deployed, but it also not completely inconceivable that an RIR RPKI CA experience such an outage [1]. For network operators following reasonable deployment practices, an RIR RPKI CA outage should result in a fallback to unvalidated network routing data and no significant network impacts. However, it’s likely not a reasonable assumption that all network operators will have properly designed and implemented best practices in this regard, so there will very likely be some networks that experience significant impacts consequential to any RIR RPKI CA outage. Even if this is only 1 or 2 percent of network operators with such configuration issues, it will mean hundreds of ISP outages occurring simultaneously throughout the Internet and millions of customers (individuals and businesses) effected globally. While the Internet is the world’s largest cooperative endeavor, there inevitably will be many folks impacted of a RIR RPKI outage, including some asking (appropriately) the question of “who should bear responsibility” for the harm that they suffered. It is worth understanding what the network community believes is the most appropriate answer to this question, since a common outlook on this question can be used to guide implementation details to match. Additionally, a common understanding on this question will provide real insight into how the network community intends risk of the system to be distributed among the participants. There are several possible options worth considering: A) The most obvious answer for the party that should be held liable for the impacts that result from an RPKI CA failure would be the respective RIR that experienced the outage. This seems rather straightforward until one considers that the RIRs are providing these services specifically noting that they may not be (despite all precautions) available 100% percent of the time, and clearly documented expectations that those relying on RPKI CA information for routing origin validation should be fallback to routing with not validated state [2]. The impacted parties are those customers of ISPs that improperly handled the unavailability of RPKI data; thus escalating situation into a network-affecting outage. Under these circumstances, directing the claims from customers of all the improperly-configured ISP’s to the RIR completely ignores the responsibility of these ISPs to prepare for this precise eventuality, as was done by the fellow network operators. B) One of the more interesting theories on who should be held liable is that those who are publishing ROA’s are the appropriate responsible parties in the event of RPKI CA failure; one can achieve such a position on the logic that they consciously decided to use RPKA CA services and thus asserted globally that they would henceforth have validated routes – an RPKI CA failure is a case of their “vendor" (the RIR) letting them down on the publication. This also has equity issues, since those publishing ROA information don’t have a clear contributory role, and the damages accruing to them are coming from customers from those operators who failed their duty. C) Another potential answer for the party that should be responsible is that each of the ISPs that failed to appropriately configure their route validation and thus experience a network outage should be responsible for their own customers impacted as a result. In addition to keeping the liability proportional to the customers served, this encourages each such ISP to consider appropriate corrective measures. It is possible to architect the various legalities surrounding RPKI to support any of the above outcomes, but it first requires a shared understanding of what the network community believes is the correct outcome. There is likely some on the nanog mailing list who have a view on this matter, so I pose the question of "who should be responsible" for consequences of RPKI RIR CA failure to this list for further discussion. Thanks! /John John Curran President and CEO American Registry for Internet Numbers (ARIN) [1] https://www.ietf.org/mail-archive/web/sidr/current/msg05621.html [2] https://www.rfc-editor.org/rfc/rfc7115.txt -------------- next part -------------- An HTML attachment was scrubbed... URL: From maillists at krassi.biz Sun Sep 30 22:30:42 2018 From: maillists at krassi.biz (Krassimir Tzvetanov) Date: Sun, 30 Sep 2018 15:30:42 -0700 Subject: NANOG Security Track: Route Security In-Reply-To: References: Message-ID: Sam, To ensure unimpeded information sharing and discussion, the Security Track will not be broadcast or recorded. I apologise for the inconvenience. Regards, Krassimir On Sun, Sep 30, 2018, 1:05 PM Sam Oduor wrote: > Hi > > Any online link available for remote participation or viewing ? > > On Sun, Sep 30, 2018 at 7:46 PM Krassimir Tzvetanov > wrote: > >> Hello Everyone, >> >> I wanted to attract your attention to the Security Track this coming >> NANOG. We'll be meeting on Tuesday morning and the line up looks like this: >> * Andre Toonk - examples of hijacks, other ideas >> * Alexander Azimov - State of BGP Security >> * David Wishnick - ARIN TAL >> * Job Snijders - Routing security roadmap >> * Chris Morrow - So I need to start filtering routes from peers...' and >> 'hey guess who needs to update their IRR data?' >> >> Time permitting at the end of the time slot we'll have a panel and time >> for duscussion as well. >> >> Regards, >> Krassi >> >> > > -- > Samson Oduor > -------------- next part -------------- An HTML attachment was scrubbed... URL: