Re: [proj-bgp] adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor?
Montgomery, Douglas (Fed): > Our effort to get our new monitor transitioned to a public facing > system ran into a wall for ~35 days. Unfortunately during that time, > the visa of a visiting researcher leading that effort expired. > > We have almost recovered from all of that. Unfortunately, we have a > bit of a bureaucracy to deploying public facing systems. So I would > guess it will take ~end of March to get it on-line. I'm curious, are there any updates on this topic? thanks! nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu signature.asc Description: OpenPGP digital signature
Re: [proj-bgp] adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor?
Montgomery, Douglas (Fed): > Our effort to get our new monitor transitioned to a public facing > system ran into a wall for ~35 days. Unfortunately during that time, > the visa of a visiting researcher leading that effort expired. > > We have almost recovered from all of that. Unfortunately, we have a > bit of a bureaucracy to deploying public facing systems. So I would > guess it will take ~end of March to get it on-line. thanks for the status update! -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu signature.asc Description: OpenPGP digital signature
Re: [proj-bgp] adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor?
Sriram, Kotikalapudi (Fed) (2018-09-18):> 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. Can you share an estimate for when you plan to publish the new version of the NIST Monitor? thanks, nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu signature.asc Description: OpenPGP digital signature
US based networks suffering from RPKI misconfigurations
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
the prefixes that wont be able to reach Cloudflare by the end of the year (unless RPKI ROAs are fixed)
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 signature.asc Description: OpenPGP digital signature
Re: Reaching out to ARIN members about their RPKI INVALID prefixes
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 signature.asc Description: OpenPGP digital signature
Re: Reaching out to ARIN members about their RPKI INVALID prefixes
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 signature.asc Description: OpenPGP digital signature
Re: Reaching out to ARIN members about their RPKI INVALID prefixes
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 signature.asc Description: OpenPGP digital signature
Re: Reaching out to ARIN members about their RPKI INVALID prefixes
> 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 signature.asc Description: OpenPGP digital signature
Re: Reaching out to ARIN members about their RPKI INVALID prefixes
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 signature.asc Description: OpenPGP digital signature
Re: Reaching out to ARIN members about their RPKI INVALID prefixes
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 signature.asc Description: OpenPGP digital signature
Reaching out to ARIN members about their RPKI INVALID prefixes
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 signature.asc Description: OpenPGP digital signature
adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor?
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 signature.asc Description: OpenPGP digital signature
RIR outreach program about INVALIDs (was: deploying RPKI based Origin Validation)
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_ signature.asc Description: OpenPGP digital signature
Re: Best practices on logical separation of abuse@ vs dmca@ role inboxes
John Levine: > In article you write: >> The main issue with the notion of keeping abuse@ separate from a >> dedicated DMCA takedown mailbox is companies like IP Echelon will just >> blindly E-mail whatever abuse POC is associated with either the AS >> record or whichever POCs are specifically associated with the NET block. >> >> So it becomes kind of difficult to keep them routing to different >> places. >> >> The guys doing the DMCA takedowns use automated tooling. So asking >> them nicely isn't going to help you. > > Seems to me that if you've registered your DMCA address in the Library > of Congress database, and they send takedowns somewhere else, that's > their problem, not not yours. > > If you haven't registered, you should. You can do the whole thing > online in a couple of minutes. The fee is $6 per update no matter how > many business names and domain names you register. > > See https://www.copyright.gov/dmca-directory/ thanks this is useful. has anyone practical experience with how many of the usual DMCA email sending companies actually take this into account when they send their automated emails? Does creating a record there actually result in a substantial fraction of DMCA emails being routed to the email address given there? -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu signature.asc Description: OpenPGP digital signature
