- Test - lists.nanog.org

NTT now treats RPKI ROAs as IRR route(6)-objects
by Job Snijders 20 Jul '18

20 Jul '18

Dear NANOG, [ TL:DR - From now on, NTT / AS 2914 allows customers to either register their announcements in the IRR, or as RPKI ROAs. This is a convenience service for relevant regions of the world where IRR is not the norm but RPKI is commonly available. Previously NTT only accepted IRR and ARIN-WHOIS. I hope competitors and partners will use this approach too! ] As most of you know, the Resource Public Key Infrastructure (RPKI) is a modern reimagination of the good ole' IRR system we have come to love and hate. The main advantage of the RPKI is that a consumer of the data can cryptographically verify whether it was the actual owner of the IP prefix that created a so-called "RPKI ROA". (more reading: https://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure) Given that RPKI ROAs are somewhat equivalent to IRR route-objects, but more reliable in terms of authoritativeness, NTT now has an automated nightly process that converts RPKI information into IRR format so that our toolchain can consume the data as if it were just another IRR source. Using RPKI ROAs as if they are IRR route(6)-objects is a transitional step towards increased security in the routing ecosystem. We are not the first to explore this method (see post-scriptum), but I think we are the first to republish elements from RPKI ROAs via a publicly accessible IRRd instance queryable with the RADB IRRd protocol. This means that anyone that points their bgpq3 or peval programs at rr.ntt.net can leverage this method without having to update anything else in the pipeline. An example can be inspected here: job@eng0 ~$ whois -h rr.ntt.net 193.0.6.139 [Querying rr.ntt.net] [rr.ntt.net] route: 193.0.0.0/21 descr: RIPE-NCC origin: AS3333 mnt-by: RIPE-NCC-MNT changed: unread(a)ripe.net 20000101 source: RIPE remarks: **************************** remarks: * THIS OBJECT IS MODIFIED remarks: * Please note that all data that is generally regarded as personal remarks: * data has been removed from this object. remarks: * To view the original object, please query the RIPE Database at: remarks: * http://www.ripe.net/whois remarks: **************************** route: 193.0.0.0/21 descr: RPKI ROA for 193.0.0.0/21 remarks: This route object represents routing data retrieved from the RPKI remarks: The original data can be found here: https://rpki.gin.ntt.net/r/AS3333/193.0.0.0/21 remarks: This route object is the result of an automated RPKI-to-IRR conversion process. remarks: maxLength 21 origin: AS3333 mnt-by: MAINT-JOB changed: job(a)ntt.net 20180718 source: RPKI # Trust Anchor: RIPE NCC RPKI Root job@eng0 ~$ The first object is an actual IRR "route:" object from the RIPE NCC operated IRR, the second object is a representation of the RPKI ROA in RPSL format published via rr.ntt.net. In general we can state that RPKI data is very good quality data, however please keep in mind that it may not be /correct/ data. In this context "Good Quality" means that it cannot easily be forged or tampered with by adversaries (but of course that doesn't protect the legitimate owner against making misconfigurations). Just like with IRR route(6)-objects, owners may input the wrong origin ASN in this type of object or configure the wrong MaxLength. NTT operates a "RPKI Cache Validator" at https://rpki.gin.ntt.net/ Everyone is free to inspect and click around in this webinterface. Instead of https://rpki.gin.ntt.net/, there also is a command line interface available via BGPMon's whois service: job@vurt ~$ whois -h whois.bgpmon.com 193.0.0.0/21 % This is the BGPmon.net whois Service % You can use this whois gateway to retrieve information % about an IP adress or prefix % We support both IPv4 and IPv6 address. % % For more information visit: % https://portal.bgpmon.net/bgpmonapi.php Prefix: 193.0.0.0/21 Prefix description: RIPE-NCC Country code: NL Origin AS: 3333 Origin AS Name: Reseaux IP Europeens Network Coordination Centre (RIPE NCC) RPKI status: ROA validation successful First seen: 2011-10-19 Last seen: 2018-07-19 Seen by #peers: 77 Notice in the above output the "ROA validation successful". Nota bene: the fact that NTT uses RPKI ROA information in the prefix filter generation process - does _not_ mean that NTT does "RPKI Origin Validation" for BGP updates (yet). RPKI Origin Validation is an additional security layer that we hope to deploy in the not too distant future. Using RPKI ROAs in this way is an important step forward in this process. Kind regards, Job Snijders Post scriptum on prior work: Dragon Research Labs implemented the idea in 2015: https://github.com/dragonresearch/rpki.net/blob/master/potpourri/roa-to-irr… RIPE NCC's RPKI Validator added RPSL export functionality in 2015: https://mailman.nanog.org/pipermail/nanog/2015-May/075185.html Arouteserver added native support for this method in October 2017. https://github.com/pierky/arouteserver/issues/19

2 1

Re: Proving Gig Speed
by Scott Weeks 19 Jul '18

19 Jul '18

--- mark.tinka(a)seacom.mu wrote: From: Mark Tinka <mark.tinka(a)seacom.mu> On 19/Jul/18 22:43, Scott Weeks wrote: > I know we're talking about Africa and other less well > connected countries, but good luck with that in the > Pacific, which covers about 1/3 of the planet. > > https://oceanexplorer.noaa.gov/facts/pacific-size.html Yeah, things and people tend to work better if hosted on land... ----------------------------------------------------- I believe I'm on land here... ;) And there're a lot of islands with lots of people out here. 1/3 of the planet and all. :) scott

1 0

Re: Proving Gig Speed
by Scott Weeks 19 Jul '18

19 Jul '18

--- mark.tinka(a)seacom.mu wrote: From: Mark Tinka <mark.tinka(a)seacom.mu> On 18/Jul/18 16:58, K. Scott Helms wrote: > ... What's really interesting is how gaming is changing > and within the next few years I do expect a lot of games > to move into the remote rendering world. You need to > have <=30 ms of latency to sustain 1080p gaming and > obviously jitter and packet loss are also problematic. > The traffic is also pretty impressive with spikes of > over 50 mbps down and sustained averages over 21 mbps. And what we need is for them to ensure all these remote rendering farms are evenly distributed around the world to ensure that 30ms peak latency is achievable. ----------------------------------------------- I know we're talking about Africa and other less well connected countries, but good luck with that in the Pacific, which covers about 1/3 of the planet. https://oceanexplorer.noaa.gov/facts/pacific-size.html scott

2 1

Re: deploying RPKI based Origin Validation
by Joshua Vijsma / True 19 Jul '18

19 Jul '18

Hi all, Just wanted to share our (AS15703, True B.V.) experience as a hosting provider with enabling RPKI invalid filtering (invalid == reject). We've secured (most of) our routes since 2014 with ROAs but last Tuesday we have deployed filters which reject RPKI invalid routes. We have had two tickets regarding users in one certain RPKI invalid prefix not being able to reach our network, but those people quickly understood that this wasn't our problem but a problem with their hosting partner. They took it up with their hosting partner and it was fixed within a day. Overal, I would certainly recommend filtering RPKI invalids (and create ROAs for your prefixes!!) to prevent hijacks. -- Met vriendelijke groet / Best regards, Joshua Vijsma > On 13 Jul 2018, at 14:00, nanog-request(a)nanog.org wrote: > > > ------------------------------ > > Message: 2 > Date: Thu, 12 Jul 2018 17:50:29 +0000 > From: Job Snijders <job(a)ntt.net> > To: nanog(a)nanog.org > Subject: deploying RPKI based Origin Validation > Message-ID: <20180712175029.GC3037(a)vurt.meerval.net> > Content-Type: text/plain; charset=us-ascii > > Hi all, > > I wanted to share with you that a ton of activity is taking place in the > Dutch networker community to deploy RPKI based BGP Origin Validation. > The mantra is "invalid == reject" on all EBGP sessions. > > What's of note here is that we're now seeing the first commercial ISPs > doing Origin Validation. This is a significant step forward compared to > what we observed so far (it seemed OV was mostly limited to academic > institutions & toy networks). But six months ago Amsio (https://www.amsio.com/en/) > made the jump, and today Fusix deployed (https://fusix.nl/deploying-rpki/) > > We've also seen an uptake of Origin Validation at Internet Exchange > route servers: AMS-IX and FranceIX have already deployed. I've read that > RPKI OV is under consideration at a number of other exchanges. > > Other cool news is that Cloudflare launched a Certificate Transparency > initiative to help keep everyone honest. Announcement at: > https://twitter.com/grittygrease/status/1017224762542587907 > Certificate Transparency is a fascinating tool, really a necessity to > build confidence in any PKI systems. > > Anyone here working to deploy RPKI based Origin Validation in their > network and reject invalid announcements? Anything of note to share? > > Kind regards, > > Job

1 0

Centurylink/Level3 Plans
by James Breeden 19 Jul '18

19 Jul '18

Does anyone know what the plans or even watercooler chat is concerning Centurylink (AS209) and Level3 (AS3356) integration, direct peering, or continuing separation? We are looking at a IP Transit deal involving one or both networks and while I'd love to have transit routes from both, I don't want to design to be shot in the foot later on either if they are talking about soon-to-be integrated or something. TIA... 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(a)arenalgroup.co<mailto:james@arenalgroup.co> | office 512.360.0000 | cell 512.304.0745 | www.arenalgroup.co<http://www.arenalgroup.co>

4 3

Quickstart Guide to IRR/RPSL
by Kenneth Finnegan 19 Jul '18

19 Jul '18

Greetings, As part of setting up a new Internet Exchange in Fremont, California, we've been investigating prefix filtering on the route servers based on IRR. Unfortunately, we were not satisfied with any of the existing documentation available online as far as taking a network engineer from "zero" to "just enough IRR to post our prefixes for filtering". Lacking this documentation, it was rather unreasonable for us to turn on filtering and drop most of our peer's prefixes without a relevant whitepaper to point them to to get started. So, we wrote our own guide: http://fcix.net/whitepaper/2018/07/14/intro-to-irr-rpsl.html I thought others on this list would find our whitepaper interesting, and/or have valuable feedback based on their experience applying IRR themselves. -- Kenneth Finnegan Technical Director Fremont Cabal Internet Exchange http://fcix.net/

2 3

Implementation plan and dates for NWI5 - Out-of-region ROUTE(6) objects and removal of ASN authorisation for ROUTE(6) object creation.
by Nathalie Trenaman 19 Jul '18

19 Jul '18

Dear colleagues, In February 2018, the RIPE Database Working Group reached consensus on NWI-5 - creating out of region ROUTE(6) objects in the RIPE Database. We will soon be making changes to the way out-of-region objects are handled in the RIPE Database. It's important that database users are aware of these changes and what they mean: 1. The RIPE Routing Registry will no longer support the creation of out-of-region ROUTE(6) and AUT-NUM objects 2. Existing out-of-region objects will have their "source:” attribute changed to "RIPE-NONAUTH” 3. The creation of ROUTE(6) objects will no longer need authorisation from the ASN holder We will implement these changes in the Release Candidate environment on Thursday, 2 August and go to full production on Tuesday, 4 September. Our implementation plan can be found at: https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-imple… <https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-imple…> The RIPE Database Working Group chairs also wrote a RIPE Labs article that describes the background of NWI-5: https://labs.ripe.net/Members/denis/out-of-region-route-6-and-aut-num-objec… <https://labs.ripe.net/Members/denis/out-of-region-route-6-and-aut-num-objec…> <https://labs.ripe.net/Members/denis/out-of-region-route-6-and-aut-num-objec… <https://labs.ripe.net/Members/denis/out-of-region-route-6-and-aut-num-objec…>> Please contact ripe-dbm(a)ripe.net <mailto:ripe-dbm@ripe.net> if you still have questions after reading the implementation plan. Best regards, Nathalie Trenaman Product Manager RIPE NCC

1 0

Re: Proving Gig Speed
by nanog-isp＠mail.com 19 Jul '18

19 Jul '18

No, but you can connect iPhones with gigabit Ethernet over copper. Jared >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike >Hammett >Cc: NANOG list >Subject: Re: Proving Gig Speed > > I don't think iPhones have SFP cages. > > > > >----- >Mike Hammett >Intelligent Computing Solutions >http://www.ics-il.com > >Midwest-IX >http://www.midwest-ix.com

1 0

NANOG list errors
by Andy Ringsmuth 19 Jul '18

19 Jul '18

Fellow list members, The last several days, I’ve been receiving mail forwarding loop errors for the list. I’ll receive them several hours after sending a message. I’ll paste the latest two of them below, separated by % symbols. Anyone able to sort this out and fix? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% This is the mail system at host mail.nanog.org. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system <nanog(a)nanog.org>: mail forwarding loop for nanog(a)nanog.org Reporting-MTA: dns; mail.nanog.org X-Postfix-Queue-ID: 2B72F160040 X-Postfix-Sender: rfc822; andy(a)newslink.com Arrival-Date: Wed, 18 Jul 2018 03:41:57 +0000 (UTC) Final-Recipient: rfc822; nanog(a)nanog.org Original-Recipient: rfc822;nanog(a)nanog.org Action: failed Status: 5.4.6 Diagnostic-Code: X-Postfix; mail forwarding loop for nanog(a)nanog.org From: Andy Ringsmuth <andy(a)newslink.com> Subject: Re: Proving Gig Speed Date: July 17, 2018 at 9:53:01 AM CDT To: NANOG list <nanog(a)nanog.org> > On Jul 17, 2018, at 9:41 AM, Mike Hammett <nanog(a)ics-il.net> wrote: > > 10G to the home will be pointless as more and more people move away from Ethernet to WiFi where the noise floor for most installs prevents anyone from reaching 802.11n speeds, much less whatever alphabet soup comes later. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com Well, in a few years when we’re all watching 4D 32K Netflix on our 16-foot screens with 5 million DPI, it’ll make all the difference in the world, right? Tongue-in-cheek obviously. ---- Andy Ringsmuth andy(a)newslink.com News Link – Manager Technology, Travel & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% This is the mail system at host mail.nanog.org. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system <nanog(a)nanog.org>: mail forwarding loop for nanog(a)nanog.org Reporting-MTA: dns; mail.nanog.org X-Postfix-Queue-ID: 2F2AA160040 X-Postfix-Sender: rfc822; andy(a)newslink.com Arrival-Date: Wed, 18 Jul 2018 03:46:02 +0000 (UTC) Final-Recipient: rfc822; nanog(a)nanog.org Original-Recipient: rfc822;nanog(a)nanog.org Action: failed Status: 5.4.6 Diagnostic-Code: X-Postfix; mail forwarding loop for nanog(a)nanog.org From: Andy Ringsmuth <andy(a)newslink.com> Subject: Re: Proving Gig Speed Date: July 17, 2018 at 11:12:22 AM CDT To: NANOG list <nanog(a)nanog.org> > On Jul 17, 2018, at 10:44 AM, Mark Tinka <mark.tinka(a)seacom.mu> wrote: > > > > On 17/Jul/18 16:41, Mike Hammett wrote: > >> 10G to the home will be pointless as more and more people move away >> from Ethernet to WiFi where the noise floor for most installs prevents >> anyone from reaching 802.11n speeds, much less whatever alphabet soup >> comes later. > > Doesn't stop customers from buying it if it's cheap and available, which > doesn't stop them from proving they are getting 10Gbps as advertised. > > Mark. I suppose in reality it’s no different than any other utility. My home has 200 amp electrical service. Will I ever use 200 amps at one time? Highly highly unlikely. But if my electrical utility wanted to advertise “200 amp service in all homes we supply!” they sure could. Would an electrician be able to test it? I’m sure there is a way somehow. If me and everyone on my street tried to use 200 amps all at the same time, could the infrastructure handle it? Doubtful. But do I on occasion saturate my home fiber 300 mbit synchronous connection? Every now and then yes, but rarely. Although if I’m paying for 300 and not getting it, my ISP will be hearing from me. If my electrical utility told me “hey, you can upgrade to 500 amp service for no additional charge” would I do it? Sure, what the heck. If my water utility said “guess what? You can upgrade to a 2-inch water line at no additional charge!” would I do it? Probably yeah, why not? Would I ever use all that capacity on $random_utility at one time? Of course not. But nice to know it’s there if I ever need it. ---- Andy Ringsmuth andy(a)newslink.com News Link – Manager Technology, Travel & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& ---- Andy Ringsmuth andy(a)newslink.com 5609 Harding Dr. Lincoln, NE 68521 (402) 304-0083 cellular

4 3

Re: Proving Gig Speed
by Mike Hammett 19 Jul '18

19 Jul '18

I don't think you understand the gravity of the in-home interference issue. Unfortunately, neither does the IEEE. It doesn't need to be in lock-step, but if a significant number of homes have issues getting over 100 megabit wirelessly, I'm not sure we need to be concerned about 10 gigabit to the home. I am well aware of the wireless world and Ubiquiti. I've been using Ubiquiti (among other brands) for over 10 years and have been a hardware beta tester for several of them. The 640 kb of RAM statements, computers in home statements, 56 kbps days statements... are all tangential at best. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Joe Greco" <jgreco(a)ns.sol.net> To: "Mike Hammett" <nanog(a)ics-il.net> Cc: nanog(a)nanog.org Sent: Tuesday, July 17, 2018 11:11:29 AM Subject: Re: Proving Gig Speed On Tue, Jul 17, 2018 at 10:47:45AM -0500, Mike Hammett wrote: > We already supply far, far greater than the actual consumer usage (versus want or demand). > > Consumers are moving away from wired connections in the home for wireless connections (for obvious mobility and ease of setup where there isn't existing wired infrastructure). > > Consumers are moving away from power desktops and laptops to phones, tablets, and purpose-built appliances. > > My in-laws have a Comcast service that's >100 megabit/s. The 2.4 and 5 GHz noise floors are so high (-50 to -75 dB, depending on channel and location within the house) that unless you're in the same room, you're not getting more than 10 megabit/s on wireless. On a wire, Comcast delivers full data rate. Speed tests from wire to wireless mirror the wireless to Internet performance. > > If it can't be delivered within the home, delivering it to the home is pointless. And yet if we had had those attitudes back in the days of 56kbps, ... Your argument is flawed because it implies that this is not an issue that can be addressed. Populating a house with more than a single crap-grade built-into-the-CPE radio is certainly possible, and tech people have been using gear such as Ubiquiti to do so for years now, but more recently mesh systems have become readily available as well and are even sold at Best Buy and other electronics stores. There is no need for ISP speeds to be in exact lock-step with wifi speeds. Advances in one will drive advances in the other. Eventually. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

4 3