From fischerdouglas at gmail.com Tue Feb 23 11:14:11 2021 From: fischerdouglas at gmail.com (Douglas Fischer) Date: Tue, 23 Feb 2021 08:14:11 -0300 Subject: [RPKI] IETF draft - The Use of Maxlength in the RPKI Message-ID: I don't know if this is the best forum to discuss this ... If not, I apologize. So far I was not aware of this draft, which already has 6 versions, and is heading towards the final version. https://tools.ietf.org/html/draft-ietf-sidrops-rpkimaxlen-06 As far as I could understand, the main reason for proposing this draft is to enable a safe and fast way to make the security of the RPKI origin validation also include the cases of RTBH ads that are generally of unique IPs (/ 32 or / 128 ). Honestly, so far I am undecided as to whether this is the best methodology for such a solution. Until now I was adopting (especially for route-servers) the methodology of further analyzing the possible status of RPKI. - Valid -> complements do not fit - Unknown -> complements do not fit - Invalid -> by previous ROA Date - Invalid -> by Later ROA Date - Invalid -> by ASN of Origin - Invalid -> for less specific mask - Invalid -> by more specific mask Thus, in the route filtering tests received against Blackhole I was using the following logic: If (is into AS-SET My-Customer) and \ (has Black-Hole-Community) and \ ((is IPv4 and is /32) or (is IPv6 and is /128)) and \ ((is RPKI Valid) or (is RPKI unknow) or (is RPKI invalid by mas more specific)) then \ accept as Blackhole... P.S.: This is a very summarized way to express the logic... I had to do some gymnastics to implement it... Converting RPKI JSONs belonging to each AS-SET to Prefix-lists. So I would like to hear from other colleagues about this Draft, and it will change the way every ASN should filter RPKI, specially RTBH. -- Douglas Fernando Fischer Eng? de Controle e Automa??o -------------- next part -------------- An HTML attachment was scrubbed... URL: From benm at workonline.africa Tue Feb 23 11:42:02 2021 From: benm at workonline.africa (Ben Maddison) Date: Tue, 23 Feb 2021 13:42:02 +0200 Subject: [RPKI] IETF draft - The Use of Maxlength in the RPKI In-Reply-To: References: Message-ID: <20210223114202.uvfpmtz7jf52jvao@benm-laptop> Hi Douglas, On 02/23, Douglas Fischer via RPKI wrote: > I don't know if this is the best forum to discuss this ... > If not, I apologize. > The SIDROPS WG list would probably be a better bet, but we can start here! > So far I was not aware of this draft, which already has 6 versions, and is > heading towards the final version. > > https://tools.ietf.org/html/draft-ietf-sidrops-rpkimaxlen-06 > > As far as I could understand, the main reason for proposing this draft is > to enable a safe and fast way to make the security of the RPKI origin > validation also include the cases of RTBH ads that are generally of unique > IPs (/ 32 or / 128 ). > I think that you have misunderstood the intention of the draft, and in particular the latest version (which made substantial changes to the section that deals with RTBH). The point of the draft is to call attention to that fact that creating ROAs which permit the origination of more-specific prefixes than are usually present in the DFZ creates an attack vector that can be exploited by hijackers. E.g. if I create a ROA: 41.78.188.0/22, maxLength: 24, asID: 37271 But then only originate: 41.78.188.0/22, AS_PATH 37271 Then an attacker can announce: 41.78.191.0/24, AS_PATH 666_37271 And will likely succeed in becoming the best path. It was observed that this issue is particularly present in ROAs where the issuer had made use of the maxLength field - hence the title of the draft. The draft also points out that because RTBH routes are typically for much longer prefixes, operators might be tempted to use maxLength to allow those routes to be ROV valid, and that doing so is a bad idea, because it creates the above attack vector. It doesn't try to propose any solution to the real issue of how ROV/RTBH should co-exist beyond that. If you think that any of the above could be made clearer in the current text, please feel free to propose changes. > Honestly, so far I am undecided as to whether this is the best methodology > for such a solution. > > Until now I was adopting (especially for route-servers) the methodology of > further analyzing the possible status of RPKI. > - Valid -> complements do not fit > - Unknown -> complements do not fit > - Invalid -> by previous ROA Date > - Invalid -> by Later ROA Date > - Invalid -> by ASN of Origin > - Invalid -> for less specific mask > - Invalid -> by more specific mask > > Thus, in the route filtering tests received against Blackhole I was using > the following logic: > > If (is into AS-SET My-Customer) and \ > (has Black-Hole-Community) and \ > ((is IPv4 and is /32) or (is IPv6 and is /128)) and \ > ((is RPKI Valid) or (is RPKI unknow) or (is RPKI invalid by mas more > specific)) then \ > accept as Blackhole... > > P.S.: This is a very summarized way to express the logic... I had to do > some gymnastics to implement it... Converting RPKI JSONs belonging to each > AS-SET to Prefix-lists. > That algorithm looks mostly sensible, and roughly similar to how we (AS37271) are planning to implement this in the next couple of months. However, I'd like to stress that is *not* proposed in draft-ietf-sidrops-rpkimaxlen. Doing that would require an update to RFC6811, and I would argue strongly against it! Cheers, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From moritz.muller at sidn.nl Thu Feb 25 09:51:20 2021 From: moritz.muller at sidn.nl (=?utf-8?Q?Moritz_M=C3=BCller?=) Date: Thu, 25 Feb 2021 10:51:20 +0100 Subject: [RPKI] Changing RPKI state Message-ID: <61E7E97D-C74C-4F7C-9DE5-15044A33DDD9@sidn.nl> Hi, I?m starting to getting more familiar with RPKI, but I?m making an observation for which I haven?t found an explanation yet. Every morning at 2 AM UTC, I?m exporting the current VRPs with " routinator vrps -f csv --complete?. Then, I?m checking with the exported list if certain prefixes are ?protected?. If I fetch VRPs a few hours later, I get significantly different results. E.g. tonight, prefixes AS16509,52.208.0.0/13 and AS13335,173.245.58.0/24 did not have a VRP, but now they have. I?ve noticed such changes on a few occasions now and I?m wondering if such fluctuation is expected? Or is there something going wrong when fetching VRPs on my side? Thanks. Moritz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From luuk at nlnetlabs.nl Thu Feb 25 10:37:42 2021 From: luuk at nlnetlabs.nl (Luuk Hendriks) Date: Thu, 25 Feb 2021 11:37:42 +0100 Subject: [RPKI] Changing RPKI state In-Reply-To: <61E7E97D-C74C-4F7C-9DE5-15044A33DDD9@sidn.nl> References: <61E7E97D-C74C-4F7C-9DE5-15044A33DDD9@sidn.nl> Message-ID: <20210225103742.GA1509939@corley.shackle.nl> Hey Moritz, On Thu 25 Feb 2021, 10:51, Moritz M?ller via RPKI wrote: > If I fetch VRPs a few hours later, I get significantly different results. > E.g. tonight, prefixes AS16509,52.208.0.0/13 and AS13335,173.245.58.0/24 did not have a VRP, but now they have. People are creating new ROAs all the time, so new VRPs appearing in your output is to be expected. Similarly, you will also find VRPs disappearing. You say 'significantly different': if you have any numbers we could compare. Perhaps you find https://rpki.today useful here: it's a tool we made to get insights in exactly those (dis)appearings. As you can see, in the last 24 hours, 317 new VRPs appeared under ARIN, 202 under RIPE NCC, etc. (Note that development of rpki.today is on hold, as we are considering merging it into JDR. Still, if you have any question about it, do let me know.) > I?ve noticed such changes on a few occasions now and I?m wondering if such fluctuation is expected? > Or is there something going wrong when fetching VRPs on my side? Assuming you don't spot obvious errors with regards to connectivity to repository servers in your logs, my guess is you are simply seeing the same differences as listed on rpki.today. Which, again, are perfectly normal and a sign that adoption of RPKI is increasing. HTH, luuk -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From swmike at swm.pp.se Thu Feb 25 10:56:43 2021 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 25 Feb 2021 11:56:43 +0100 (CET) Subject: [RPKI] offlist Re: Changing RPKI state In-Reply-To: <20210225103742.GA1509939@corley.shackle.nl> References: <61E7E97D-C74C-4F7C-9DE5-15044A33DDD9@sidn.nl> <20210225103742.GA1509939@corley.shackle.nl> Message-ID: On Thu, 25 Feb 2021, Luuk Hendriks via RPKI wrote: > (Note that development of rpki.today is on hold, as we are considering > merging it into JDR. Still, if you have any question about it, do let me > know.) Hi, thanks for providing this tool, seems valuable. Just wanted to tell you what I just observed: chloe.sobornost.net was rebooted, and that resulted in https://rpki.today/ showing it with VRP-, probably because no objects could be fetched during that reboot. So if I look at "last hour": chloe.sobornost.net SE ?AS1883 1 1 0 1 0 chloe.sobornost.net SE ?AS1880 1 1 0 1 0 But if I look at last 24 hours, it doesn't show these. These ROAs were not deleted or anything, from what I can tell and asking Job, he just rebooted the server. So if this is expected behavior from not being able to fetch (if it's indeed that), then everything is fine. If this is not intended behavior, I just wanted you to know. Thanks! -- Mikael Abrahamsson email: swmike at swm.pp.se From alex at nlnetlabs.nl Thu Feb 25 11:27:13 2021 From: alex at nlnetlabs.nl (Alex Band) Date: Thu, 25 Feb 2021 12:27:13 +0100 Subject: [RPKI] Discontinuing 1-Click Apps for Krill Message-ID: Dear mailing list, About one year ago we introduced a 1-Click App for Krill on the AWS Marketplace and DigitalOcean Marketplace. It was introduced in a time when installing and configuring Krill involved quite some steps. The goal was to allow operators to get started with Krill quickly, to gain operational experience with delegated RPKI. Since then, we have introduced Debian and Ubuntu packages for Krill on the NLnet Labs package repository, which will soon offer RPM packages as well. We also offer a Docker container image and a public RPKI testbed. All these solutions have significantly reduced the need for the 1-Click Apps. Nowadays, getting started with Krill is as simple as "apt install krill? and opening the Krill user interface in a browser. As a result, we are discontinuing the AWS Marketplace and the DigitalOcean Marketplace 1-Click Apps. Existing installations will keep working, but will no longer receive updates. On behalf of the NLnet Labs RPKI Team, Alex From luuk at nlnetlabs.nl Thu Feb 25 11:51:52 2021 From: luuk at nlnetlabs.nl (Luuk Hendriks) Date: Thu, 25 Feb 2021 12:51:52 +0100 Subject: [RPKI] offlist Re: Changing RPKI state In-Reply-To: References: <61E7E97D-C74C-4F7C-9DE5-15044A33DDD9@sidn.nl> <20210225103742.GA1509939@corley.shackle.nl> Message-ID: <20210225115152.GA1535100@corley.shackle.nl> Hi Mikael, Fair question, and probably something that should be better explained on the page itself: rpki.today gives you a diff between $time_A and $time_B. E.g. by default, when landing on the page, that will be $24h_ago and $now, if you will. If in the mean time something disappeared and appeared again (with the exact same prefixes and ASID), it will not show up in the diff. So this is indeed expected behavior. FWIW, from the Atlas measurements (also shown in JDR) it seems that chloe.sobornost.net might have some network issues (after the reboot?): https://atlas.ripe.net/measurements/28478831/#probes https://atlas.ripe.net/measurements/28478830/#probes https://atlas.ripe.net/measurements/28478580/#probes https://atlas.ripe.net/measurements/28478579/#probes Thanks, luuk On Thu 25 Feb 2021, 11:56, Mikael Abrahamsson via RPKI wrote: > On Thu, 25 Feb 2021, Luuk Hendriks via RPKI wrote: > > > (Note that development of rpki.today is on hold, as we are considering > > merging it into JDR. Still, if you have any question about it, do let me > > know.) > > Hi, > > thanks for providing this tool, seems valuable. > > Just wanted to tell you what I just observed: > > chloe.sobornost.net was rebooted, and that resulted in https://rpki.today/ > showing it with VRP-, probably because no objects could be fetched during > that reboot. > > So if I look at "last hour": > > chloe.sobornost.net SE ?AS1883 1 1 0 1 0 > chloe.sobornost.net SE ?AS1880 1 1 0 1 0 > > But if I look at last 24 hours, it doesn't show these. These ROAs were not > deleted or anything, from what I can tell and asking Job, he just rebooted > the server. > > So if this is expected behavior from not being able to fetch (if it's indeed > that), then everything is fine. If this is not intended behavior, I just > wanted you to know. > > Thanks! > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > -- > RPKI mailing list > RPKI at lists.nlnetlabs.nl > https://lists.nlnetlabs.nl/mailman/listinfo/rpki From swmike at swm.pp.se Thu Feb 25 12:00:32 2021 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 25 Feb 2021 13:00:32 +0100 (CET) Subject: [RPKI] offlist Re: Changing RPKI state In-Reply-To: <20210225115152.GA1535100@corley.shackle.nl> References: <61E7E97D-C74C-4F7C-9DE5-15044A33DDD9@sidn.nl> <20210225103742.GA1509939@corley.shackle.nl> <20210225115152.GA1535100@corley.shackle.nl> Message-ID: On Thu, 25 Feb 2021, Luuk Hendriks via RPKI wrote: > Hi Mikael, > > Fair question, and probably something that should be better explained on > the page itself: rpki.today gives you a diff between $time_A and > $time_B. E.g. by default, when landing on the page, that will be > $24h_ago and $now, if you will. If in the mean time something > disappeared and appeared again (with the exact same prefixes and ASID), > it will not show up in the diff. > > So this is indeed expected behavior. Sorry, I intended to send this to you offlist but ... I failed. Anyhow, my point was about definition of "disappeared". Did something disappear if the server wasn't reachable and thus it's unknown what the state is? One way to look at it: If I can't get it (timeout), it's not there. Another way to look at it: If I can't get it (timeout), I have no idea, I'll presume last known state is still true and I'll presume anything I fetched previously is still relevant until it expires. So basically, should the tool behave like it has a cache or should it behave like if it's cold-starting each time. Thanks. -- Mikael Abrahamsson email: swmike at swm.pp.se From moritz.muller at sidn.nl Thu Feb 25 13:39:06 2021 From: moritz.muller at sidn.nl (=?utf-8?Q?Moritz_M=C3=BCller?=) Date: Thu, 25 Feb 2021 14:39:06 +0100 Subject: [RPKI] Changing RPKI state In-Reply-To: <20210225103742.GA1509939@corley.shackle.nl> References: <61E7E97D-C74C-4F7C-9DE5-15044A33DDD9@sidn.nl> <20210225103742.GA1509939@corley.shackle.nl> Message-ID: <915D4F01-4A54-49F7-B3B4-F10D742754E8@sidn.nl> Hi Luuk, Thanks for pointing me to rpki.today. That helps a lot with debugging. And I wasn?t aware that VRPs are that ?unstable?. > > Perhaps you find https://rpki.today useful here: it's a tool we made to > get insights in exactly those (dis)appearings. As you can see, in the last > 24 hours, 317 new VRPs appeared under ARIN, 202 under RIPE NCC, etc. In my case, I see 22,189 prefixes at 11:00 AM UTC that I haven?t seen tonight at 2:00 am. 21991 of which are at the arin TA. > > Assuming you don't spot obvious errors with regards to connectivity to > repository servers in your logs, my guess is you are simply seeing the > same differences as listed on rpki.today. Which, again, are perfectly > normal and a sign that adoption of RPKI is increasing. I do see two, I believe, noteworthy errors in the logs though: RRDP hash mismatch in local file .rsync://.rpki.arin.net./.repository./.arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/f60c9f32-a87c-4339-a2f3-6299a3b02e29/51446bec-6773-47fb-9bf6-b260de4b6968/51446bec-6773-47fb-9bf6-b260de4b6968.mft. RRDP hash mismatch in local file rsync://rpki.afrinic.net/repository./ member_repository/F36FBB68/DEFB17F0767311EBBA1F686DF8AEA228/DRUACGUUibpRRLPxfr7M37lFZAs.mft Moritz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From tim at nlnetlabs.nl Thu Feb 25 13:57:13 2021 From: tim at nlnetlabs.nl (Tim Bruijnzeels) Date: Thu, 25 Feb 2021 14:57:13 +0100 Subject: [RPKI] Changing RPKI state In-Reply-To: <20210225103742.GA1509939@corley.shackle.nl> References: <61E7E97D-C74C-4F7C-9DE5-15044A33DDD9@sidn.nl> <20210225103742.GA1509939@corley.shackle.nl> Message-ID: <21EEF93D-D165-40D1-92DD-6040F76346ED@nlnetlabs.nl> Hi, > On 25 Feb 2021, at 11:37, Luuk Hendriks via RPKI wrote: > >> I?ve noticed such changes on a few occasions now and I?m wondering if such fluctuation is expected? >> Or is there something going wrong when fetching VRPs on my side? > > Assuming you don't spot obvious errors with regards to connectivity to > repository servers in your logs, my guess is you are simply seeing the > same differences as listed on rpki.today. Which, again, are perfectly > normal and a sign that adoption of RPKI is increasing. I would expect that these fluctuations match the actual changes in BGP. This could be interesting research, provided you have detailed enough history of both BGP and VRPs. My hypothesis would be that a longitudinal analysis would show that it's related to RPKI uptake, especially w.r.t. validation which gives a strong incentive to fix ROAs if they disagree with your routing intent. So I would expect that the change rate in ROAs increasingly matches changes in BGP, and that possible delays in ROA updates wrt BGP are now getting shorter. Tim From tdekock at ripe.net Thu Feb 25 14:55:47 2021 From: tdekock at ripe.net (Ties de Kock) Date: Thu, 25 Feb 2021 15:55:47 +0100 Subject: [RPKI] offlist Re: Changing RPKI state In-Reply-To: References: <61E7E97D-C74C-4F7C-9DE5-15044A33DDD9@sidn.nl> <20210225103742.GA1509939@corley.shackle.nl> <20210225115152.GA1535100@corley.shackle.nl> Message-ID: Hi all, > On 25 Feb 2021, at 13:00, Mikael Abrahamsson via RPKI wrote: > > On Thu, 25 Feb 2021, Luuk Hendriks via RPKI wrote: > >> Hi Mikael, >> >> Fair question, and probably something that should be better explained on >> the page itself: rpki.today gives you a diff between $time_A and >> $time_B. E.g. by default, when landing on the page, that will be >> $24h_ago and $now, if you will. If in the mean time something >> disappeared and appeared again (with the exact same prefixes and ASID), >> it will not show up in the diff. >> >> So this is indeed expected behavior. > > Sorry, I intended to send this to you offlist but ... I failed. > > Anyhow, my point was about definition of "disappeared". Did something disappear if the server wasn't reachable and thus it's unknown what the state is? > > One way to look at it: If I can't get it (timeout), it's not there. > > Another way to look at it: If I can't get it (timeout), I have no idea, I'll presume last known state is still true and I'll presume anything I fetched previously is still relevant until it expires. > > So basically, should the tool behave like it has a cache or should it behave like if it's cold-starting each time. My experience is that it depends on both the software you use and on the current state of the cache. The RP implementations that I have been using update the state from the repository if the repository is available. If it is not available, the last version (if not expired) is used. I?m not sure if there is an RFC describing this behaviour. When updating from rrdp or rsync, octorpki, RPKI validator 3, and routinator delete objects that are no longer present. rpki-client does not delete objects (?delete with rsync) that still are referenced: it only purges objects that are not referenced from the object tree. In the end, the state that you observe can differ between a clean start and when you have a cache. Kind regards, Ties From luuk at nlnetlabs.nl Fri Feb 26 09:21:58 2021 From: luuk at nlnetlabs.nl (Luuk Hendriks) Date: Fri, 26 Feb 2021 10:21:58 +0100 Subject: [RPKI] offlist Re: Changing RPKI state In-Reply-To: References: <61E7E97D-C74C-4F7C-9DE5-15044A33DDD9@sidn.nl> <20210225103742.GA1509939@corley.shackle.nl> <20210225115152.GA1535100@corley.shackle.nl> Message-ID: <20210226092158.GA1577103@corley.shackle.nl> Hi Mikael, all, On Thu 25 Feb 2021, 13:00, Mikael Abrahamsson wrote: > Anyhow, my point was about definition of "disappeared". Did something > disappear if the server wasn't reachable and thus it's unknown what the > state is? > > One way to look at it: If I can't get it (timeout), it's not there. > > Another way to look at it: If I can't get it (timeout), I have no idea, I'll > presume last known state is still true and I'll presume anything I fetched > previously is still relevant until it expires. > > So basically, should the tool behave like it has a cache or should it behave > like if it's cold-starting each time. The data behind rpki.today is (the csvext-formatted) output from Routinator which, in case of connectivity issues, uses older data from an earlier fetch. So in case of an unreachable server, VRPs will not be shown as 'disappeared' as long as they are still valid timewise. Hope that clarifies, cheers, luuk