- NANOG - lists.nanog.org

Report on Legal Barriers to RPKI Adoption
by Christopher S. Yoo 09 Jan '19

09 Jan '19

As many of you know, the prospects for widespread RPKI adoption grew more promising in 2018. Cloudflare issued route origin authorizations ("ROAs") to cover 25% of its prefixes, including its 1.1.1.1 resolver and DNS servers. NTT began treating RPKI ROAs as if they were IRR route(6)-objects. Google announced its intention to begin filtering routes in early 2019. The Mutually Agreed Norms for Routing Security now has over 100 network operators signed on. Still, as 2019 begins, many worry that legal issues are hindering RPKI adoption. This is especially true for North American networks, which have a comparatively low percentage of IPv4 space covered by ROAs, and whose ROAs are comparatively underutilized by parties using RPKI-based route origin validation ("ROV") to inform their routing decisions. My coauthor (David Wishnick) and I have spent the past year delving into the legal issues surrounding RPKI. Today, we are publicizing our report on how the network operator community should address these issues. It is available here<https://ssrn.com/abstract=3308619>. If you are interested in the future of routing security, we encourage you to read it (or its Executive Summary). We've tried to keep the legalese to a minimum. RPKI was a major topic of discussion at NANOG 74 and ARIN 42 in Vancouver. Going forward, we expect to continue a fruitful dialogue about how the network operator community can reduce the legal barriers to RPKI adoption. Here is a summary of our recommendations: On the ROV side of the equation, the principal legal hindrances have to do with the terms and conditions governing access to the RPKI repository offered by ARIN in its Relying Party Agreement ("RPA"), and in the manner it has employed to ensure the agreement is binding. Regarding ROV: 1. The goal of widespread ROV counsels in favor of ARIN reviewing its current approach to repository distribution, embodied in the RPA. We conclude that two paths would be reasonable. First, ARIN should consider dropping the RPA altogether. This would remove the most significant legal barriers to widespread utilization of the ARIN RPKI repository. Second, because the legal risks faced by ARIN in an RPA-free world are ultimately uncertain, it would also be reasonable for ARIN to maintain the RPA for the purposes of contractually allocating risks to the parties best positioned to reduce and mitigate them. If ARIN keeps the RPA, ARIN should consider removing the RPA's indemnification clause, instead relying solely on the RPA's disclaimers of warranties and limitations of liability, or at least reducing the indemnification clause's scope to eliminate the problem of moral hazard. 2. Developers of RPKI validation software should consider integrating acceptance of ARIN's RPA into their software workflows. ARIN recently enabled this possibility, and developers should deliberate on whether to capitalize on the opportunity. 3. The network operator community and ARIN should broadly publicize ARIN's policy of revising various RPA clauses for government entities that are prohibited from agreeing to them. 4. In addition to the important step ARIN has already taken to enable third-party software developers to integrate RPA acceptance into their software workflows, ARIN should consider reducing the barriers to third-party service development imposed by the RPA's prohibited conduct clause. Specifically, ARIN should consider methods for allowing approved developers to make use of RPKI information as an input into more sophisticated services. 5. Separately, ARIN should consider revising the prohibited conduct clause to allow broader distribution of information created with RPKI as an input for research and analysis purposes. 6. As a general alternative, the Internet community should consider whether to develop a separate corporate entity that would be responsible for operational aspects of RPKI repository provision. That corporation could conduct such activities for the North American region, or on a worldwide basis. Regarding the ROA-issuance side of the equation, the principal legal obstacles stem from the terms and conditions found in ARIN's Registration Services Agreement ("RSA"), Legacy Registration Services Agreement ("LRSA"), and RPKI Terms of Service. Regarding these, the report recommends the following: 1. ARIN should consider adopting a pathway to provide RPKI services that would explicitly refrain from altering the existing balance of property and transferability rights associated with IP address allocations. 2. The network operator community and ARIN should broadly publicize ARIN's policy of revising certain RSA/LRSA and RPKI Terms of Service clauses for government entities that are prohibited from agreeing to them. ARIN should also begin presenting the RPKI Terms of Service to newly-onboarded members alongside their RSA/LRSA, so that organizations spend less time dealing with legal issues overall. Separately, the report recommends that the network operator community consider whether to encourage companies and the federal government to include RPKI adoption in procurement best practices or requirements. In tandem with recommendations designed to encourage adoption, the report also makes two recommendations concerning operational readiness for widespread RPKI deployment. Specifically: 1. To reduce any legal risks associated with RPKI, the network operator community should focus on adopting operational best practices. No system is 100% reliable across all contingencies; as a result, operators should prepare for outages and other headaches. RPKI implementations should be resilient in the face of such contingencies. 2. The five RIRs should work to ensure readiness for widespread RPKI adoption and strive to publicize deeper details on their service-level intentions to the Internet community. This research is supported by NSF Award No. 1748362. The contents of the report represent our independent views, not those of the NSF. Any mistakes, of course, are also ours alone. Christopher S. Yoo John H. Chestnut Professor of Law, Communication, and Computer & Information Science Founding Director, Center for Technology, Innovation and Competition University of Pennsylvania Law School 3501 Sansom St. Philadelphia, PA 19104-6204 (215) 746-8772 (o) (215) 573-2025 (f) csyoo(a)law.upenn.edu<mailto:csyoo@law.upenn.edu> http://www.law.upenn.edu/faculty/csyoo/ For more information on the Center for Technology, Innovation and Competition, see https://www.law.upenn.edu/institutes/ctic/.

4 3

RE: BGP Experiment
by adamv0025＠netconsultings.com 08 Jan '19

08 Jan '19

> Steve Noble > Sent: Tuesday, January 8, 2019 6:42 PM > > There is no such thing as a fully RFC compliant BGP : > Which RFC do you mean 6286, 6608, 6793, 7606, 7607, 7705 or 8212 when you say fully RFC compliant BGP please? > https://www.juniper.net/documentation/en_US/junos/topics/reference/st > andards/bgp.html does not list 7606 > > Cisco Bug: CSCvf06327 - Error Handling for RFC 7606 not implemented for > NXOS > > This is as of today and a 2 second google search.. anyone running code from > before RFC 7606 (2015) would also not be compliant. > With regards to Revised Error Handling for BGP UPDATE Messages RFC 7606, My recollection is there was a very long discussion with working code preceding the various drafts as well as the final RFC standard. Regarding the Juniper case specifically a bit of googling reveals that: All Junos software releases built on or after 2009-06-29 have been enhanced to be more tolerant of malformed optional, transitive attributes. Releases containing the coding change specifically include: 9.1S2, 9.3R3, 9.6R1 and all subsequent releases (i.e. all releases built after 9.6R1). -so it's not quite black and white, there will be levels of protection available in current releases (albeit not fully compliant with RFC per se). Question is whether folks out there have it actually enabled. Oh and then there are bugs associated with the new feature (like the one in some versions of Junos which ,upon receiving malformed update won't bring the session down but rather the whole rpd if the bgp-error-tolerance feature is enabled ) adam

1 0

Spoofer Report for NANOG for Dec 2018
by CAIDA Spoofer Project 08 Jan '19

08 Jan '19

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 Dec 2018: ASN Name Fixed-By 393422 NEWVISIONS-CNY 2018-12-10 20009 WADSNET 2018-12-11 7922 COMCAST-7922 2018-12-14 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Dec 2018: ASN Name First-Spoofed Last-Spoofed 40065 CNServersLLC 2016-05-01 2018-12-22 7029 WINDSTREAM 2016-06-21 2018-12-14 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2018-12-27 6128 CABLE-NET-1 2016-09-03 2018-12-22 20412 CLARITY-TELECOM 2016-09-30 2018-12-26 6181 FUSE-NET 2016-10-10 2018-12-27 15305 SYRINGANETWORKS 2016-10-21 2018-12-15 25787 ROWE-NETWORKS 2016-10-21 2018-12-28 174 COGENT-174 2016-10-21 2018-12-20 31857 PRIORITY-TERABIT 2016-10-25 2018-12-28 30341 SCTA-ASN 2016-10-31 2018-12-31 32440 LONI 2016-11-03 2018-12-20 33182 DimeNOC 2016-11-08 2018-12-28 12083 WOW-INTERNET 2016-11-09 2018-12-31 13427 SOFTCOM-INTERNET-COMMUNICATION 2016-11-14 2018-12-25 3549 LVLT-3549 2016-11-16 2018-12-13 21832 KELLINCOM-1 2017-02-03 2018-12-27 7122 MTS-ASN 2017-05-16 2018-12-24 701 UUNET 2017-06-14 2018-12-09 6461 ZAYO-6461 2017-06-21 2018-12-14 63296 AMARILLO-WIRELESS 2017-09-01 2018-12-26 7233 YAHOO-US 2017-09-07 2018-12-21 33523 ROWANUNIVERSITY 2017-10-29 2018-12-17 546 PARSONS-PGS-1 2017-11-20 2018-12-19 12222 AKAMAI 2018-02-14 2018-12-30 29384 Qatar-Foundation 2018-03-08 2018-12-26 23148 TERRENAP 2018-03-15 2018-12-26 8100 ASN-QUADRANET-GLOBAL 2018-04-06 2018-12-26 4201 ORST 2018-04-19 2018-12-27 11827 WSU 2018-04-19 2018-12-28 35911 BNQ-1 2018-06-06 2018-12-18 225 VIRGINIA 2018-06-18 2018-12-19 2381 WISCNET1 2018-09-04 2018-12-26 54804 CSMIII-BUNKIELA 2018-09-15 2018-12-30 33452 RW 2018-09-19 2018-12-27 20448 VPNTRANET-LLC 2018-09-20 2018-12-26 11215 LOGIXCOMM 2018-09-20 2018-12-13 11996 LOBOIS 2018-09-24 2018-12-27 19919 VSW 2018-10-23 2018-12-13 13825 TROYCABLE-NET 2018-11-21 2018-12-22 6453 AS6453 2018-12-11 2018-12-20 62957 HOSPITALITY-NETWORK 2018-12-30 2018-12-30 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… Please send any feedback or suggestions to spoofer-info(a)caida.org

1 0

Changing upstream providers, opinions/thoughts on 123.net and cogent
by Aaron Henderson 08 Jan '19

08 Jan '19

I work for a rural ISP and the powers that be have been thinking about changing our upstream providers. The big names on the table right now are 123.net and Cogent. I, along with the people in my circle, do not have any experience with these providers and all we are getting is what sales are dishing us. I was hoping some of you here might have experience with these providers and could share your experiences and opinions. Thanks, A

5 4

Astronaut accidently calls 911 from space
by Sean Donelan 07 Jan '19

07 Jan '19

I was disappointed that it was just a misdial. I was looking forward to how IP geolocation worked with 9-1-1 calls from space. I always wondered how that altitude parameter in 911 packets was used. :-) https://www.newsweek.com/astronaut-accidentally-calls-911-space-1276892

2 1

attempted archive.is hijacking
by Dan Hollis 07 Jan '19

07 Jan '19

https://twitter.com/archiveis/status/1081276424781287427 Wonder what tactic the hijackers are using, and if it would work with any registrar - or if there is something specific about isnic that allows it to happen. -Dan

3 2

Re: Cleveland/Cincinnati Co-location
by David Kehoe 07 Jan '19

07 Jan '19

Former employer was in Expedient’s DC. You can honestly do better than Expedient. Look into the Power Redundancy, Cooling Efficiency of the building, if the site is a purpose built DC (Expedient in Cleveland is not). Is Cloud Connect for backups important? Have you identified your requirements? If you need a starting point look at the following: Data Center Certification (from the Uptime Institute), Distance, Compliance (if needed), Level of Controlled Access, Power SLA, N+1 Cooling, Multi-Homed ISPs, Uptime %, Monitoring, NOC, Purpose Built DC. Involta has a really good data center in Independence, Akron, and a very impressive site near Pittsburgh. They would give you the option of having Hot/Hot datacenters with their connectivity. I’m not sure if you have to be in Cleveland or Cincinnati, but Cyxtera has an AMAZING data center in Columbus. (The DC can withstand winds up 140 MPH, is on the Century Link backbone, and has a solid rubber roof with no holes or cooling systems on the roof.) Thank you, David Kehoe From: NANOG <nanog-bounces(a)nanog.org> On Behalf Of nanog-request(a)nanog.org Sent: Friday, January 4, 2019 7:00 AM To: nanog(a)nanog.org Subject: NANOG Digest, Vol 132, Issue 4 Send NANOG mailing list submissions to nanog(a)nanog.org<mailto:nanog@nanog.org> To subscribe or unsubscribe via the World Wide Web, visit https://mailman.nanog.org/mailman/listinfo/nanog<https://mailman.nanog.org/mailman/listinfo/nanog> or, via email, send a message with subject or body 'help' to nanog-request(a)nanog.org<mailto:nanog-request@nanog.org> You can reach the person managing the list at nanog-owner(a)nanog.org<mailto:nanog-owner@nanog.org> When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. Re: Cleveland/Cincinnati Co-location (Allen McKinley Kitchen (gmail)) 2. Re: Service Provider NetFlow Collectors (Aaron) 3. Re: Cleveland/Cincinnati Co-location (Shawn Ritchie) 4. Re: Announcing Peering-LAN prefixes to customers (Andy Davidson) 5. Report on Legal Barriers to RPKI Adoption (Christopher S. Yoo) 6. 192.208.19.0/24<http://192.208.19.0/24> hijack transiting 209, 286, 3320, 5511, 6461, 6762, 6830, 8220, 9002, 12956 (Dominik Bay) 7. Re: 192.208.19.0/24<http://192.208.19.0/24> hijack transiting 209, 286, 3320, 5511, 6461, 6762, 6830, 8220, 9002, 12956 (Jeff Shultz) 8. Astronaut accidently calls 911 from space (Sean Donelan) 9. Re: Cellular backup connections (Dovid Bender) 10. Re: 192.208.19.0/24<http://192.208.19.0/24> hijack transiting 209, 286, 3320, 5511, 6461, 6762, 6830, 8220, 9002, 12956 (Job Snijders) ---------------------------------------------------------------------- Message: 1 Date: Thu, 3 Jan 2019 10:50:45 -0500 From: "Allen McKinley Kitchen (gmail)" <allenmckinleykitchen(a)gmail.com<mailto:allenmckinleykitchen@gmail.com>> To: "Justin M. Streiner" <streinerj(a)gmail.com<mailto:streinerj@gmail.com>> Cc: NANOG <nanog(a)nanog.org<mailto:nanog@nanog.org>> Subject: Re: Cleveland/Cincinnati Co-location Message-ID: <91679AF9-E310-463C-B427-630F69C02222(a)gmail.com<mailto:91679AF9-E310-463C-B427-630F69C02222@gmail.com>> Content-Type: text/plain; charset=us-ascii +1 for Expedient. Not a current customer but a VERY satisfied former customer. (Decision to leave them was a foul case of penny-pincher mismanagement, above my pay grade and over my objections.) ..Allen > On Jan 3, 2019, at 01:00, Justin M. Streiner <streinerj(a)gmail.com<mailto:streinerj@gmail.com>> wrote: > >> On Tue, 1 Jan 2019, Mitchell Lewis wrote: >> >> I am working on project that may involve building points of presence in Cleveland & Cincinnati. Any suggestions as to which colocation facility in each city to build in? The prime factor of consideration for this project is access to waves to places like Chicago, New York & Ashburn. It would be nice to have multiple wave provider options to choose from. >> >> I have been looking at Cyrus One-7thStreet in Cincinnati & Databank in Cleveland. > > Expedient has two facilities in Cleveland that might be worth looking at. > > Thank you > jms ------------------------------ Message: 2 Date: Thu, 3 Jan 2019 10:40:44 +0900 From: Aaron <aaron_ppus(a)fmad.com<mailto:aaron_ppus@fmad.com>> To: "Michel 'ic' Luczak" <lists(a)benappy.com<mailto:lists@benappy.com>> Cc: Erik Sundberg <ESundberg(a)nitelusa.com<mailto:ESundberg@nitelusa.com>>, "nanog(a)nanog.org<mailto:nanog@nanog.org>" <nanog(a)nanog.org<mailto:nanog@nanog.org>> Subject: Re: Service Provider NetFlow Collectors Message-ID: <CABq4n+TREPexPGWJJRdgRJZSuLBhVpO9pEd5mxz+Vn7p122FaQ(a)mail.gmail.com<mailto:CABq4n+TREPexPGWJJRdgRJZSuLBhVpO9pEd5mxz+Vn7p122FaQ@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" Throwing my hat in the ring also (vendor from fmadio) https://github.com/fmadio/pcap2json<https://github.com/fmadio/pcap2json> Not exactly a newflow collector, its pcap -> flowgen -> elk on a single box, working very well so far, still work in progress. Problem with logstash is its too slow for high flow rates. So we did everything inside the flow generator for direct ELK bulk uploads removing logstash completely. Cheers Aaron On Mon, 31 Dec 2018 at 18:40, Michel 'ic' Luczak <lists(a)benappy.com<mailto:lists@benappy.com>> wrote: > Don’t underestimate good old ELK > https://www.elastic.co/guide/en/logstash/current/netflow-module.html<https://www.elastic.co/guide/en/logstash/current/netflow-module.html> > + https://github.com/robcowart/elastiflow<https://github.com/robcowart/elastiflow> > > BR, ic > > On 31 Dec 2018, at 04:29, Erik Sundberg <ESundberg(a)nitelusa.com<mailto:ESundberg@nitelusa.com>> wrote: > > Hi Nanog…. > > We are looking at replacing our Netflow collector. I am wonder what other > service providers are using to collect netflow data off their Core and Edge > Routers. Pros/Cons… What to watch out for any info would help. > > We are mainly looking to analyze the netflow data. Bonus if it does ddos > detection and mitigation. > > We are looking at > ManageEngine Netflow Analyzer > PRTG > Plixer – Scrutinizer > PeakFlow > Kentik > Solarwinds NTA > > > Thanks in advance… > > Erik > > > ------------------------------ > > 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: <http://mailman.nanog.org/pipermail/nanog/attachments/20190103/2975478b/atta…<http://mailman.nanog.org/pipermail/nanog/attachments/20190103/2975478b/atta…>> ------------------------------ Message: 3 Date: Thu, 3 Jan 2019 11:21:32 -0600 From: Shawn Ritchie <me(a)shawnritchie.com<mailto:me@shawnritchie.com>> To: "Allen McKinley Kitchen (gmail)" <allenmckinleykitchen(a)gmail.com<mailto:allenmckinleykitchen@gmail.com>> Cc: "Justin M. Streiner" <streinerj(a)gmail.com<mailto:streinerj@gmail.com>>, NANOG <nanog(a)nanog.org<mailto:nanog@nanog.org>> Subject: Re: Cleveland/Cincinnati Co-location Message-ID: <19433FF4-0E0C-4D7A-9CF2-CF385AE0AAB1(a)fastmail.fm<mailto:19433FF4-0E0C-4D7A-9CF2-CF385AE0AAB1@fastmail.fm>> Content-Type: text/plain; charset=utf-8 On Jan 3, 2019, at 9:50 AM, Allen McKinley Kitchen (gmail) <allenmckinleykitchen(a)gmail.com<mailto:allenmckinleykitchen@gmail.com>> wrote: > > +1 for Expedient. Not a current customer but a VERY satisfied former customer. (Decision to leave them was a foul case of penny-pincher mismanagement, above my pay grade and over my objections.) > > ..Allen > >> On Jan 3, 2019, at 01:00, Justin M. Streiner <streinerj(a)gmail.com<mailto:streinerj@gmail.com>> wrote: >> >>> On Tue, 1 Jan 2019, Mitchell Lewis wrote: >>> >>> I am working on project that may involve building points of presence in Cleveland & Cincinnati. Any suggestions as to which colocation facility in each city to build in? The prime factor of consideration for this project is access to waves to places like Chicago, New York & Ashburn. It would be nice to have multiple wave provider options to choose from. >>> >>> I have been looking at Cyrus One-7thStreet in Cincinnati & Databank in Cleveland. >> >> Expedient has two facilities in Cleveland that might be worth looking at. >> >> Thank you >> jms I’m in Expedient’s Cleveland DC and will second that they’re decent. — Shawn ------------------------------ Message: 4 Date: Thu, 3 Jan 2019 20:08:46 +0000 From: Andy Davidson <andy(a)nosignal.org<mailto:andy@nosignal.org>> To: Dominic Schallert <ds(a)schallert.com<mailto:ds@schallert.com>> Cc: "nanog(a)nanog.org<mailto:nanog@nanog.org>" <nanog(a)nanog.org<mailto:nanog@nanog.org>> Subject: Re: Announcing Peering-LAN prefixes to customers Message-ID: <34E9593E-5004-4A01-BAFC-E56CA6520433(a)nosignal.org<mailto:34E9593E-5004-4A01-BAFC-E56CA6520433@nosignal.org>> Content-Type: text/plain; charset="utf-8" Hi, Dominic -- On 20/12/2018, 17:49, Dominic Schallert <ds(a)schallert.com<mailto:ds@schallert.com>> wrote: > this might be a stupid question but today I was discussing with a colleague if > Peering-LAN prefixes should be re-distributed/announced to direct customers/peers. > My standpoint is that in any case, Peering-LAN prefixes should be filtered and not > announced to peers/customers because a Peering-LAN represents some sort of > DMZ and there is simply no need for them to be reachable by third-parties not being > physically connected to an IXP themselves. There are no stupid questions! It is a good idea to not BGP announce and perhaps also to drop traffic toward peering LAN prefixes at customer-borders, this was already well discussed in the thread. But there wasn’t a discussion on how we got to this point. Until the Cloudflare 2013 BGP speaker attack, that sought to flood Cloudflare’s transfer networks and exchange connectivity (and with it saturating IXP inter-switch links and IXP participant ports), it was common for IXP IPv4/6 peering LANs to be internet reachable and BGP transited. This facilitated troubleshooting (e.g. traceroutes showing peering lan interfaces in traceroutes instead of ‘starring out’) and PMTUD (e.g. see recommendation in https://www.ripe.net/ripe/mail/archives/ipv6-wg/2011-July/001839.html<https://www.ripe.net/ripe/mail/archives/ipv6-wg/2011-July/001839.html> which actually asked for IXP peering LANs to be announced). There are good reasons to announce but there are better reasons to filter. The security benefits of filtering outweigh the upsides on today’s internet, but fashions and best practice may further evolve over time. Andy -- Andy Davidson Director, Asteroid International BV www.asteroidhq.com<http://www.asteroidhq.com> Director, Euro-IX - The European Internet Exchange Association www.euro-ix.net<http://www.euro-ix.net> ------------------------------ Message: 5 Date: Thu, 3 Jan 2019 20:51:56 +0000 From: "Christopher S. Yoo" <csyoo(a)law.upenn.edu<mailto:csyoo@law.upenn.edu>> To: "nanog(a)nanog.org<mailto:nanog@nanog.org>" <nanog(a)nanog.org<mailto:nanog@nanog.org>> Cc: David Wishnick <dwishn(a)law.upenn.edu<mailto:dwishn@law.upenn.edu>> Subject: Report on Legal Barriers to RPKI Adoption Message-ID: <BYAPR01MB4936273F035E0BE12EB3DCD8FD8D0(a)BYAPR01MB4936.prod.exchangelabs.com<mailto:BYAPR01MB4936273F035E0BE12EB3DCD8FD8D0@BYAPR01MB4936.prod.exchangelabs.com>> Content-Type: text/plain; charset="utf-8" As many of you know, the prospects for widespread RPKI adoption grew more promising in 2018. Cloudflare issued route origin authorizations ("ROAs") to cover 25% of its prefixes, including its 1.1.1.1<http://1.1.1.1> resolver and DNS servers. NTT began treating RPKI ROAs as if they were IRR route(6)-objects. Google announced its intention to begin filtering routes in early 2019. The Mutually Agreed Norms for Routing Security now has over 100 network operators signed on. Still, as 2019 begins, many worry that legal issues are hindering RPKI adoption. This is especially true for North American networks, which have a comparatively low percentage of IPv4 space covered by ROAs, and whose ROAs are comparatively underutilized by parties using RPKI-based route origin validation ("ROV") to inform their routing decisions. My coauthor (David Wishnick) and I have spent the past year delving into the legal issues surrounding RPKI. Today, we are publicizing our report on how the network operator community should address these issues. It is available here<https://ssrn.com/abstract=3308619<https://ssrn.com/abstract=3308619>>. If you are interested in the future of routing security, we encourage you to read it (or its Executive Summary). We've tried to keep the legalese to a minimum. RPKI was a major topic of discussion at NANOG 74 and ARIN 42 in Vancouver. Going forward, we expect to continue a fruitful dialogue about how the network operator community can reduce the legal barriers to RPKI adoption. Here is a summary of our recommendations: On the ROV side of the equation, the principal legal hindrances have to do with the terms and conditions governing access to the RPKI repository offered by ARIN in its Relying Party Agreement ("RPA"), and in the manner it has employed to ensure the agreement is binding. Regarding ROV: 1. The goal of widespread ROV counsels in favor of ARIN reviewing its current approach to repository distribution, embodied in the RPA. We conclude that two paths would be reasonable. First, ARIN should consider dropping the RPA altogether. This would remove the most significant legal barriers to widespread utilization of the ARIN RPKI repository. Second, because the legal risks faced by ARIN in an RPA-free world are ultimately uncertain, it would also be reasonable for ARIN to maintain the RPA for the purposes of contractually allocating risks to the parties best positioned to reduce and mitigate them. If ARIN keeps the RPA, ARIN should consider removing the RPA's indemnification clause, instead relying solely on the RPA's disclaimers of warranties and limitations of liability, or at least reducing the indemnification clause's scope to eliminate the problem of moral hazard. 2. Developers of RPKI validation software should consider integrating acceptance of ARIN's RPA into their software workflows. ARIN recently enabled this possibility, and developers should deliberate on whether to capitalize on the opportunity. 3. The network operator community and ARIN should broadly publicize ARIN's policy of revising various RPA clauses for government entities that are prohibited from agreeing to them. 4. In addition to the important step ARIN has already taken to enable third-party software developers to integrate RPA acceptance into their software workflows, ARIN should consider reducing the barriers to third-party service development imposed by the RPA's prohibited conduct clause. Specifically, ARIN should consider methods for allowing approved developers to make use of RPKI information as an input into more sophisticated services. 5. Separately, ARIN should consider revising the prohibited conduct clause to allow broader distribution of information created with RPKI as an input for research and analysis purposes. 6. As a general alternative, the Internet community should consider whether to develop a separate corporate entity that would be responsible for operational aspects of RPKI repository provision. That corporation could conduct such activities for the North American region, or on a worldwide basis. Regarding the ROA-issuance side of the equation, the principal legal obstacles stem from the terms and conditions found in ARIN's Registration Services Agreement ("RSA"), Legacy Registration Services Agreement ("LRSA"), and RPKI Terms of Service. Regarding these, the report recommends the following: 1. ARIN should consider adopting a pathway to provide RPKI services that would explicitly refrain from altering the existing balance of property and transferability rights associated with IP address allocations. 2. The network operator community and ARIN should broadly publicize ARIN's policy of revising certain RSA/LRSA and RPKI Terms of Service clauses for government entities that are prohibited from agreeing to them. ARIN should also begin presenting the RPKI Terms of Service to newly-onboarded members alongside their RSA/LRSA, so that organizations spend less time dealing with legal issues overall. Separately, the report recommends that the network operator community consider whether to encourage companies and the federal government to include RPKI adoption in procurement best practices or requirements. In tandem with recommendations designed to encourage adoption, the report also makes two recommendations concerning operational readiness for widespread RPKI deployment. Specifically: 1. To reduce any legal risks associated with RPKI, the network operator community should focus on adopting operational best practices. No system is 100% reliable across all contingencies; as a result, operators should prepare for outages and other headaches. RPKI implementations should be resilient in the face of such contingencies. 2. The five RIRs should work to ensure readiness for widespread RPKI adoption and strive to publicize deeper details on their service-level intentions to the Internet community. This research is supported by NSF Award No. 1748362. The contents of the report represent our independent views, not those of the NSF. Any mistakes, of course, are also ours alone. Christopher S. Yoo John H. Chestnut Professor of Law, Communication, and Computer & Information Science Founding Director, Center for Technology, Innovation and Competition University of Pennsylvania Law School 3501 Sansom St. Philadelphia, PA 19104-6204 (215) 746-8772 (o) (215) 573-2025 (f) csyoo(a)law.upenn.edu<mailto:csyoo@law.upenn.edu<mailto:csyoo@law.upenn.edu%3cmailto:csyoo@law.upenn.edu>> http://www.law.upenn.edu/faculty/csyoo/<http://www.law.upenn.edu/faculty/csyoo/> For more information on the Center for Technology, Innovation and Competition, see https://www.law.upenn.edu/institutes/ctic/<https://www.law.upenn.edu/institutes/ctic/>. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190103/82ae6154/atta…<http://mailman.nanog.org/pipermail/nanog/attachments/20190103/82ae6154/atta…>> ------------------------------ Message: 6 Date: Thu, 3 Jan 2019 22:01:56 +0000 From: Dominik Bay <db(a)rrbone.net<mailto:db@rrbone.net>> To: "nanog(a)nanog.org<mailto:nanog@nanog.org>" <nanog(a)nanog.org<mailto:nanog@nanog.org>> Subject: 192.208.19.0/24<http://192.208.19.0/24> hijack transiting 209, 286, 3320, 5511, 6461, 6762, 6830, 8220, 9002, 12956 Message-ID: <4E73CA49-E9B1-4F26-9986-D64DE9E0DB06(a)rrbone.net<mailto:4E73CA49-E9B1-4F26-9986-D64DE9E0DB06@rrbone.net>> Content-Type: text/plain; charset="utf-8" I see the follwowing ASN transiting a leak concerning 192.208.19.0/24<http://192.208.19.0/24> originated by 4812 209 286 3320 5400 5511 6327 6461 6762 6830 8218 8220 8447 8551 9002 12956 The proper source is 32982 (Department of Energy). More details to be found here: https://bgpstream.com/event/171779<https://bgpstream.com/event/171779> And here: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.208.19.0<http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.208.19.0> Cheers, Dominik ------------------------------ Message: 7 Date: Thu, 3 Jan 2019 14:37:28 -0800 From: Jeff Shultz <jeffshultz(a)sctcweb.com<mailto:jeffshultz@sctcweb.com>> To: Dominik Bay <db(a)rrbone.net<mailto:db@rrbone.net>> Cc: "nanog(a)nanog.org<mailto:nanog@nanog.org>" <nanog(a)nanog.org<mailto:nanog@nanog.org>> Subject: Re: 192.208.19.0/24<http://192.208.19.0/24> hijack transiting 209, 286, 3320, 5511, 6461, 6762, 6830, 8220, 9002, 12956 Message-ID: <CAGb3Bgf60fye4W5HwLXqwvv3K06sVJmBA6HNzJywsTRjVZumXg(a)mail.gmail.com<mailto:CAGb3Bgf60fye4W5HwLXqwvv3K06sVJmBA6HNzJywsTRjVZumXg@mail.gmail.com>> Content-Type: text/plain; charset="UTF-8" China Telecom originating a network that belongs to the agency that controls all things nuclear in the US... nothing suspicious there. On Thu, Jan 3, 2019 at 2:03 PM Dominik Bay <db(a)rrbone.net<mailto:db@rrbone.net>> wrote: > > I see the follwowing ASN transiting a leak concerning 192.208.19.0/24<http://192.208.19.0/24> originated by 4812 > > 209 > 286 > 3320 > 5400 > 5511 > 6327 > 6461 > 6762 > 6830 > 8218 > 8220 > 8447 > 8551 > 9002 > 12956 > > The proper source is 32982 (Department of Energy). > More details to be found here: https://bgpstream.com/event/171779<https://bgpstream.com/event/171779> > And here: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.208.19.0<http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.208.19.0> > > Cheers, > Dominik > > -- Jeff Shultz -- Like us on Social Media for News, Promotions, and other information!! <https://www.facebook.com/SCTCWEB/<https://www.facebook.com/SCTCWEB/>> <https://www.instagram.com/sctc_503/<https://www.instagram.com/sctc_503/>> <https://www.yelp.com/biz/sctc-stayton-3<https://www.yelp.com/biz/sctc-stayton-3>> <https://www.youtube.com/c/sctcvideos<https://www.youtube.com/c/sctcvideos>> _**** This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ****_ ------------------------------ Message: 8 Date: Thu, 3 Jan 2019 17:45:00 -0500 (EST) From: Sean Donelan <sean(a)donelan.com<mailto:sean@donelan.com>> To: nanog(a)nanog.org<mailto:nanog@nanog.org> Subject: Astronaut accidently calls 911 from space Message-ID: <nycvar.OFS.7.76.4444.1901031742280.94156(a)cnex.qbaryna.pbz<mailto:nycvar.OFS.7.76.4444.1901031742280.94156@cnex.qbaryna.pbz>> Content-Type: text/plain; format=flowed; charset=US-ASCII I was disappointed that it was just a misdial. I was looking forward to how IP geolocation worked with 9-1-1 calls from space. I always wondered how that altitude parameter in 911 packets was used. :-) https://www.newsweek.com/astronaut-accidentally-calls-911-space-1276892<https://www.newsweek.com/astronaut-accidentally-calls-911-space-1276892> ------------------------------ Message: 9 Date: Thu, 3 Jan 2019 18:46:08 -0500 From: Dovid Bender <dovid(a)telecurve.com<mailto:dovid@telecurve.com>> To: Mark Milhollan <mlm(a)pixelgate.net<mailto:mlm@pixelgate.net>> Cc: NANOG <nanog(a)nanog.org<mailto:nanog@nanog.org>> Subject: Re: Cellular backup connections Message-ID: <CAM3TTh0mNx4apFpZFTXEzW4=HUM4OQND65gW3f5V2=jtdGpVyw(a)mail.gmail.com<mailto:CAM3TTh0mNx4apFpZFTXEzW4=HUM4OQND65gW3f5V2=jtdGpVyw@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" All, Thanks for all of the feedback. I was on site today and noticed two things. 1) As someone mentioned it could be for static IP's they have the traffic going to a specific location. The POP is in NJ there was a min. latency of 120ms which prob had to do with this. 2) I was watching the ping times and it looked something like this: 400ms 360ms 330ms 300ms 260ms 210ms 170ms 140ms 120ms 400ms 375ms It seems to have been coming in "waves". I assume this has to do with "how cellular work" and the signal. I tried moving it around by putting it down low on the floor, moving it locations etc. and saw the same thing every time. I am going to try Verizon next and see how it goes. On Sat, Dec 29, 2018 at 12:13 PM Mark Milhollan <mlm(a)pixelgate.net<mailto:mlm@pixelgate.net>> wrote: > On Fri, 28 Dec 2018, Dovid Bender wrote: > > >I finally got around to setting up a cellular backup device in our new > POP. > > >When SSH'ing in remotely the connection seems rather slow. > > Perhaps using MOSH can help make the interactive CLI session less > annoying. > > >Verizon they charge $500.00 just to get a public IP and I want to avoid > >that if possible. > > You might look into have it call out / maintain a connection back to > your infrastructure. > > > /mark > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190103/b4c3f157/atta…<http://mailman.nanog.org/pipermail/nanog/attachments/20190103/b4c3f157/atta…>> ------------------------------ Message: 10 Date: Fri, 4 Jan 2019 11:21:32 +0300 From: Job Snijders <job(a)ntt.net<mailto:job@ntt.net>> To: Dominik Bay <db(a)rrbone.net<mailto:db@rrbone.net>> Cc: "nanog(a)nanog.org<mailto:nanog@nanog.org>" <nanog(a)nanog.org<mailto:nanog@nanog.org>> Subject: Re: 192.208.19.0/24<http://192.208.19.0/24> hijack transiting 209, 286, 3320, 5511, 6461, 6762, 6830, 8220, 9002, 12956 Message-ID: <CACWOCC8DRPSWCvsa6n-Yyf0LwR=81APcL+HAvgOF9GHwvYhvuA(a)mail.gmail.com<mailto:CACWOCC8DRPSWCvsa6n-Yyf0LwR=81APcL+HAvgOF9GHwvYhvuA@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" Dear all, NTT / AS 2914 deployed explicit filters to block this BGP announcement from AS 4134. I recommend other operators to do the same. I’d also like to recommend AS 32982 to remove the AS_PATH prepend on the /24 announcement so the counter measure is more effective. Kind regards, Job On Fri, Jan 4, 2019 at 1:02 Dominik Bay <db(a)rrbone.net<mailto:db@rrbone.net>> wrote: > I see the follwowing ASN transiting a leak concerning 192.208.19.0/24<http://192.208.19.0/24> > originated by 4812 > > 209 > 286 > 3320 > 5400 > 5511 > 6327 > 6461 > 6762 > 6830 > 8218 > 8220 > 8447 > 8551 > 9002 > 12956 > > The proper source is 32982 (Department of Energy). > More details to be found here: https://bgpstream.com/event/171779<https://bgpstream.com/event/171779> > And here: http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.208.19.0<http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.208.19.0> > > Cheers, > Dominik > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190104/0c84b757/atta…<http://mailman.nanog.org/pipermail/nanog/attachments/20190104/0c84b757/atta…>> End of NANOG Digest, Vol 132, Issue 4 *************************************

3 3

IP Dslams
by Nick Edwards 06 Jan '19

06 Jan '19

Howdy, We have a requirement for an aged care facility to provide voice and data, we have the voice worked out, but data, WiFi is out of the question, so are looking for IP-Dslams, preferably a system that is all-in-one, or self contained, as in contains its own BBRAS/LNS/PPP server/Radius, such as has a property managment API, or even just a webpage manager where admin can add in new residents when they arive, or delete when they depart I know these used to be available many years ago, but that vendor has like many vanished, only requirement is for ADSL2+, prefer units with either 48 ports or multiples of (192 etc) and have filtered voice out ports (telco50/rj21 etc) If anyone knows of such units, would appreciate some details on them, brand/model suppliers if known, etc, we can try get out google fu back if we have some steering:) Thank Y'all (resent - original never made it to the list for some gremlin reason)

14 23

Verizon IDE
by Mitchell Lewis 05 Jan '19

05 Jan '19

How common is it for Verizon to deliver "Internet Dedicated Ethernet" over sonet? Ran into a situation where the canoga-perkins nte was uplinked to a Flashwave 4100es in the basement (uplinked by an OC-48). There is in a Verizon ILEC area. Thanks & Regards, Mitchell Lewis mlewis(a)techcompute.net

3 2

Re: Changing upstream providers, opinions/thoughts on 123.net and cogent
by Neader, Brent 05 Jan '19

05 Jan '19

Looks like they already are? https://bgp.he.net/AS14374 Depending on which peer you might be replacing 123.net or cogent with, that could possibly change someone’s opinion. However, at least from past topics on this, given cogent history with peering issues (such as HE.net cake), I think one would certainly want to understand what impact peering/routing quirks would cause them and their ability to work around them before selecting cogent. Given I doubt your international reach is a big deal, and given 123.net is more of a tier2 (https://bgp.he.net/AS12129) with local and regional peering ( https://www.peeringdb.com/net/3899 ), they could be better suited for your traffic patterns and local customers? Also if you are not already interconnected with 123.net from a transport perspective, given their footprint in the state, there could be opportunities for an NNI to expand your reach to help interconnect your customer’s locations (aka customer has a branch office inside and outside your direct footprint and wants ELAN type service). I have looked at them before but never got serious, and thus cannot offer any input on their actual service or support. From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Ben Cannon Sent: Friday, January 4, 2019 8:16 PM To: Aaron Henderson <ahenderson(a)avci.net> Cc: nanog(a)nanog.org Subject: EXT_Re: Changing upstream providers, opinions/thoughts on 123.net and cogent Run BGP and use multiple upstream providers as soon as you can. -Ben On Jan 4, 2019, at 4:57 AM, Aaron Henderson <ahenderson(a)avci.net<mailto:ahenderson@avci.net>> wrote: I work for a rural ISP and the powers that be have been thinking about changing our upstream providers. The big names on the table right now are 123.net<http://123.net/> and Cogent. I, along with the people in my circle, do not have any experience with these providers and all we are getting is what sales are dishing us. I was hoping some of you here might have experience with these providers and could share your experiences and opinions. Thanks, A

1 0