From martin at nlnetlabs.nl Fri Feb 15 09:28:16 2019 From: martin at nlnetlabs.nl (Martin Hoffmann) Date: Fri, 15 Feb 2019 10:28:16 +0100 Subject: [RPKI] =?utf-8?b?Um91dGluYXRvciAwLjMuMCDigJhJdOKAmXMgTW9yZSBG?= =?utf-8?q?un_at_the_Zoo=E2=80=99_relased?= Message-ID: <20190215102816.48eef7b9@glaurung.nlnetlabs.nl> Dear mailing list, we are elated to announce the latest release of the Routinator, version 0.3.0 ?It?s More Fun at the Zoo?. This release implements `RFC 8360 `__ which proposes an alternative mode for dealing with overclaimed resources in certificates. It promises to make it easier to deal with resources being transfered away from a holder. We have also added an HTTP service to _rtrd_ mode. It is intended primarily for monitoring - it already supports the metrics endpoint for Prometheus ?, but it also allows you to fetch the list of VRPs via your browser. We will add more extensive monitoring metrics in future releases. Finally, we fixed a bug where some serial numbers in RTR were all wrong. As always, you can see the complete changes in the Changelog at https://github.com/NLnetLabs/routinator/blob/v0.3.0/Changelog.md and find more information at https://github.com/NLnetLabs/routinator On behalf of the NLnet Labs RPKI Team, Martin From agray at blargh.com Sun Feb 24 22:40:53 2019 From: agray at blargh.com (Andrew Gray) Date: Sun, 24 Feb 2019 15:40:53 -0700 Subject: [RPKI] Potential for test/dev trust anchor? Message-ID: Hi all, At the RPKI round table before NANOG 75 last week, a few people were commenting about the inability to test or see what potential ROA entries may do, especially inside other providers networks. This seems to be somewhat of a hindrance to adoption under the "well, if I advertise nothing, things keep working, but if I screw it up, I break things" issue. I spoke with a couple other folks at that round table one-on-one, but I wanted to toss out an idea to a wider audience: Could a dev/testing trust anchor be set up by the community, and have a couple of the tier 1 providers provide feedback from that through one of the various looking glass systems? This would allow people to use that test trust anchor to verify they have advertisements correct, things do what they want, etc., before then pulling the advertisement over to whichever RIR is appropriate for production work. Thoughts? Thanks, Andrew From rpki at braeburn.org Mon Feb 25 02:19:05 2019 From: rpki at braeburn.org (Jay Borkenhagen) Date: Sun, 24 Feb 2019 21:19:05 -0500 Subject: [RPKI] Potential for test/dev trust anchor? In-Reply-To: References: Message-ID: <23667.20633.692740.803813@oz.mt.att.com> Andrew Gray writes: > [...] Could a dev/testing > trust anchor be set up by the community, and have a couple of the tier 1 > providers provide feedback from that through one of the various looking > glass systems? > > This would allow people to use that test trust anchor to verify they > have advertisements correct, things do what they want, etc., before then > pulling the advertisement over to whichever RIR is appropriate for > production work. > That sounds like a job for your RP software. For example, RIPE's rpki-validator-3 allows its operator to configure whitelist entries. After configuring a whitelist entry -- which is in essence a local ROA -- the RIPE software will show which current routes known to RIPE RIS would be validated or invalidated by the whitelist ROA. If that kind of 'what if?' analysis is important to you, you should tell your favorite RP project. (For my money, it's OK to have this, but other RP features / capabilities are more important to me.) Jay B. From job at ntt.net Mon Feb 25 02:35:30 2019 From: job at ntt.net (Job Snijders) Date: Mon, 25 Feb 2019 02:35:30 +0000 Subject: [RPKI] Potential for test/dev trust anchor? In-Reply-To: References: Message-ID: <20190225023530.GA32301@vurt.meerval.net> Hi Andrew, On Sun, Feb 24, 2019 at 03:40:53PM -0700, Andrew Gray wrote: > At the RPKI round table before NANOG 75 last week, a few people were > commenting about the inability to test or see what potential ROA > entries may do, especially inside other providers networks. This > seems to be somewhat of a hindrance to adoption under the "well, if I > advertise nothing, things keep working, but if I screw it up, I break > things" issue. > > I spoke with a couple other folks at that round table one-on-one, but > I wanted to toss out an idea to a wider audience: Could a dev/testing > trust anchor be set up by the community, and have a couple of the tier > 1 providers provide feedback from that through one of the various > looking glass systems? > > This would allow people to use that test trust anchor to verify they > have advertisements correct, things do what they want, etc., before > then pulling the advertisement over to whichever RIR is appropriate > for production work. > > Thoughts? It'll be very hard to have large transit providers run some kind of *simulation* in their *production* networks (and looking glass). Such networks would need to implement logic that somehow marks RPKI invalid BGP announcements with different communities depending on the TAL, and depending on the TAL reject or accept it. This seems like a lot of work, if you at the same time can do this simulation yourself. For instance the RIPE RPKI Validator has a 'BGP preview' feature which can perhaps be used, you'd need to stand up your own 'fake TAL' but this is where the NLNet Labs 'krill' software maybe can be of use. Kind regards, Job From agray at blargh.com Mon Feb 25 02:48:29 2019 From: agray at blargh.com (Andrew Gray) Date: Sun, 24 Feb 2019 19:48:29 -0700 Subject: [RPKI] Potential for test/dev trust anchor? In-Reply-To: <20190225023530.GA32301@vurt.meerval.net> References: <20190225023530.GA32301@vurt.meerval.net> Message-ID: On 2/24/2019 7:35 PM, Job Snijders wrote: > Hi Andrew, > > On Sun, Feb 24, 2019 at 03:40:53PM -0700, Andrew Gray wrote: >> At the RPKI round table before NANOG 75 last week, a few people were >> commenting about the inability to test or see what potential ROA >> entries may do, especially inside other providers networks. This >> seems to be somewhat of a hindrance to adoption under the "well, if I >> advertise nothing, things keep working, but if I screw it up, I break >> things" issue. >> >> I spoke with a couple other folks at that round table one-on-one, but >> I wanted to toss out an idea to a wider audience: Could a dev/testing >> trust anchor be set up by the community, and have a couple of the tier >> 1 providers provide feedback from that through one of the various >> looking glass systems? >> >> This would allow people to use that test trust anchor to verify they >> have advertisements correct, things do what they want, etc., before >> then pulling the advertisement over to whichever RIR is appropriate >> for production work. >> >> Thoughts? > > It'll be very hard to have large transit providers run some kind of > *simulation* in their *production* networks (and looking glass). Such > networks would need to implement logic that somehow marks RPKI invalid > BGP announcements with different communities depending on the TAL, and > depending on the TAL reject or accept it. I wasn't thinking this would be part of the production networks. More like a side service that is offered, with a on-the-side box doing prefix validations against a different set of TALs with a simple web front end (ala the existing looking glasses). > This seems like a lot of work, if you at the same time can do this > simulation yourself. For instance the RIPE RPKI Validator has a 'BGP > preview' feature which can perhaps be used, you'd need to stand up your > own 'fake TAL' but this is where the NLNet Labs 'krill' software maybe > can be of use. True, but I'm unsure of the availability of such a tool from the other RIRs. More to the point, this doesn't really provide the "what will Level3/NTT/WeBeInternetPeeringAndMore do with my announcement" that it seemed like people were looking for - that final reassurance that this ROA won't drop their company/ISP/what-have-you off the face of the Internet. Thanks, Andrew From agray at blargh.com Mon Feb 25 02:59:09 2019 From: agray at blargh.com (Andrew Gray) Date: Sun, 24 Feb 2019 19:59:09 -0700 Subject: [RPKI] Potential for test/dev trust anchor? In-Reply-To: <23667.20633.692740.803813@oz.mt.att.com> References: <23667.20633.692740.803813@oz.mt.att.com> Message-ID: <8964245e-c0cf-b182-9fd2-594e115d1c41@blargh.com> On 2/24/2019 7:19 PM, Jay Borkenhagen wrote: > Andrew Gray writes: > > [...] Could a dev/testing > > trust anchor be set up by the community, and have a couple of the tier 1 > > providers provide feedback from that through one of the various looking > > glass systems? > > > > This would allow people to use that test trust anchor to verify they > > have advertisements correct, things do what they want, etc., before then > > pulling the advertisement over to whichever RIR is appropriate for > > production work. > > > > That sounds like a job for your RP software. > > For example, RIPE's rpki-validator-3 allows its operator to configure > whitelist entries. After configuring a whitelist entry -- which is in > essence a local ROA -- the RIPE software will show which current > routes known to RIPE RIS would be validated or invalidated by the > whitelist ROA. > If that kind of 'what if?' analysis is important to you, you should > tell your favorite RP project. (For my money, it's OK to have this, > but other RP features / capabilities are more important to me.) This thought was based on some of the comments heard both at the RPKI gathering and at NANOG afterwards - people are very leery of deploying ROA objects at all for fear of what will happen because of those announcements. Telling operators that "If you do nothing, the worst that will happen is you're subject to prefix hijacks. If you do deploy this and have it wrong, you drop your company/ISP/what-have-you off the internet which is almost certainly a Resume Generating Event" is an extremely hard sell for network engineers to make to their management. Giving them more tools to validate things are correct in a trivial to look at and for management to see format would be valuable. I guess the root thought is - how can this level of validation made as easy and low-impacting as possible? The desire is to have a great many people sign their assignments - the fewer barriers/software needs/etc. in the way the better. Thanks, Andrew From job at ntt.net Mon Feb 25 03:02:56 2019 From: job at ntt.net (Job Snijders) Date: Mon, 25 Feb 2019 03:02:56 +0000 Subject: [RPKI] Potential for test/dev trust anchor? In-Reply-To: References: <20190225023530.GA32301@vurt.meerval.net> Message-ID: <20190225030256.GC32301@vurt.meerval.net> On Sun, Feb 24, 2019 at 07:48:29PM -0700, Andrew Gray wrote: > On 2/24/2019 7:35 PM, Job Snijders wrote: > > On Sun, Feb 24, 2019 at 03:40:53PM -0700, Andrew Gray wrote: > > > At the RPKI round table before NANOG 75 last week, a few people > > > were commenting about the inability to test or see what potential > > > ROA entries may do, especially inside other providers networks. > > > This seems to be somewhat of a hindrance to adoption under the > > > "well, if I advertise nothing, things keep working, but if I screw > > > it up, I break things" issue. > > > > > > I spoke with a couple other folks at that round table one-on-one, > > > but I wanted to toss out an idea to a wider audience: Could a > > > dev/testing trust anchor be set up by the community, and have a > > > couple of the tier 1 providers provide feedback from that through > > > one of the various looking glass systems? > > > > > > This would allow people to use that test trust anchor to verify > > > they have advertisements correct, things do what they want, etc., > > > before then pulling the advertisement over to whichever RIR is > > > appropriate for production work. > > > > > > Thoughts? > > > > It'll be very hard to have large transit providers run some kind of > > *simulation* in their *production* networks (and looking glass). > > Such networks would need to implement logic that somehow marks RPKI > > invalid BGP announcements with different communities depending on > > the TAL, and depending on the TAL reject or accept it. > > I wasn't thinking this would be part of the production networks. More > like a side service that is offered, with a on-the-side box doing > prefix validations against a different set of TALs with a simple web > front end (ala the existing looking glasses). Ah, that is more feasable, but probably won't finalize in a uniform approach across multiple transit providers / ixp route servers. At the moment of writing all looking glasses are one-offs with no industry standard. > > This seems like a lot of work, if you at the same time can do this > > simulation yourself. For instance the RIPE RPKI Validator has a 'BGP > > preview' feature which can perhaps be used, you'd need to stand up > > your own 'fake TAL' but this is where the NLNet Labs 'krill' > > software maybe can be of use. > > True, but I'm unsure of the availability of such a tool from the other > RIRs. More to the point, this doesn't really provide the "what will > Level3/NTT/WeBeInternetPeeringAndMore do with my announcement" that it > seemed like people were looking for - that final reassurance that this > ROA won't drop their company/ISP/what-have-you off the face of the > Internet. Not entirely sure, but I'd like to note that the RIPE NCC RPKI Validator works for RPKI TALs from all RIRs. It is not "RIPE specific" software. RIPE's validator software uses the RIS dataset (many networks, like NTT feed into that). Kind regards, Job From job at ntt.net Mon Feb 25 03:03:54 2019 From: job at ntt.net (Job Snijders) Date: Mon, 25 Feb 2019 03:03:54 +0000 Subject: [RPKI] Potential for test/dev trust anchor? In-Reply-To: <8964245e-c0cf-b182-9fd2-594e115d1c41@blargh.com> References: <23667.20633.692740.803813@oz.mt.att.com> <8964245e-c0cf-b182-9fd2-594e115d1c41@blargh.com> Message-ID: <20190225030354.GD32301@vurt.meerval.net> On Sun, Feb 24, 2019 at 07:59:09PM -0700, Andrew Gray wrote: > On 2/24/2019 7:19 PM, Jay Borkenhagen wrote: > > Andrew Gray writes: > > > [...] Could a dev/testing > > > trust anchor be set up by the community, and have a couple of the tier 1 > > > providers provide feedback from that through one of the various looking > > > glass systems? > > > > > > This would allow people to use that test trust anchor to verify they > > > have advertisements correct, things do what they want, etc., before then > > > pulling the advertisement over to whichever RIR is appropriate for > > > production work. > > > > > > > That sounds like a job for your RP software. > > > > For example, RIPE's rpki-validator-3 allows its operator to configure > > whitelist entries. After configuring a whitelist entry -- which is in > > essence a local ROA -- the RIPE software will show which current > > routes known to RIPE RIS would be validated or invalidated by the > > whitelist ROA. > > > If that kind of 'what if?' analysis is important to you, you should > > tell your favorite RP project. (For my money, it's OK to have this, > > but other RP features / capabilities are more important to me.) > > This thought was based on some of the comments heard both at the RPKI > gathering and at NANOG afterwards - people are very leery of deploying ROA > objects at all for fear of what will happen because of those announcements. > Telling operators that "If you do nothing, the worst that will happen is > you're subject to prefix hijacks. If you do deploy this and have it wrong, > you drop your company/ISP/what-have-you off the internet which is almost > certainly a Resume Generating Event" is an extremely hard sell for network > engineers to make to their management. Giving them more tools to validate > things are correct in a trivial to look at and for management to see format > would be valuable. > > I guess the root thought is - how can this level of validation made as easy > and low-impacting as possible? The desire is to have a great many people > sign their assignments - the fewer barriers/software needs/etc. in the way > the better. I don't know if it is of any help, but I'm happy to do a one-off analysis of your proposed ROAs based on NTT BGP data. Just mail me in CSV format the prefix, maxlenght, origin asn(s). Kind regards, Job From tim at nlnetlabs.nl Wed Feb 27 07:49:40 2019 From: tim at nlnetlabs.nl (Tim Bruijnzeels) Date: Wed, 27 Feb 2019 16:49:40 +0900 Subject: [RPKI] Potential for test/dev trust anchor? In-Reply-To: <20190225030354.GD32301@vurt.meerval.net> References: <23667.20633.692740.803813@oz.mt.att.com> <8964245e-c0cf-b182-9fd2-594e115d1c41@blargh.com> <20190225030354.GD32301@vurt.meerval.net> Message-ID: <09BD68AC-9191-425F-975B-C822525E2F39@nlnetlabs.nl> Hi, This may help: https://github.com/NLnetLabs/secure-routing-stats This is a small stand-alone (rust-based) tool that can combine ROAs (Validated ROA Payloads) from a routinator csv output, with RIS style aggregated BGP dumps and NRO stats for: * global ROA quality stats * invalids for address space X, Y, Z * unseen (stale?) ROA VRPs for address space X,Y,Z Tim > On 25 Feb 2019, at 12:03, Job Snijders wrote: > > On Sun, Feb 24, 2019 at 07:59:09PM -0700, Andrew Gray wrote: >> On 2/24/2019 7:19 PM, Jay Borkenhagen wrote: >>> Andrew Gray writes: >>>> [...] Could a dev/testing >>>> trust anchor be set up by the community, and have a couple of the tier 1 >>>> providers provide feedback from that through one of the various looking >>>> glass systems? >>>> >>>> This would allow people to use that test trust anchor to verify they >>>> have advertisements correct, things do what they want, etc., before then >>>> pulling the advertisement over to whichever RIR is appropriate for >>>> production work. >>>> >>> >>> That sounds like a job for your RP software. >>> >>> For example, RIPE's rpki-validator-3 allows its operator to configure >>> whitelist entries. After configuring a whitelist entry -- which is in >>> essence a local ROA -- the RIPE software will show which current >>> routes known to RIPE RIS would be validated or invalidated by the >>> whitelist ROA. >> >>> If that kind of 'what if?' analysis is important to you, you should >>> tell your favorite RP project. (For my money, it's OK to have this, >>> but other RP features / capabilities are more important to me.) >> >> This thought was based on some of the comments heard both at the RPKI >> gathering and at NANOG afterwards - people are very leery of deploying ROA >> objects at all for fear of what will happen because of those announcements. >> Telling operators that "If you do nothing, the worst that will happen is >> you're subject to prefix hijacks. If you do deploy this and have it wrong, >> you drop your company/ISP/what-have-you off the internet which is almost >> certainly a Resume Generating Event" is an extremely hard sell for network >> engineers to make to their management. Giving them more tools to validate >> things are correct in a trivial to look at and for management to see format >> would be valuable. >> >> I guess the root thought is - how can this level of validation made as easy >> and low-impacting as possible? The desire is to have a great many people >> sign their assignments - the fewer barriers/software needs/etc. in the way >> the better. > > I don't know if it is of any help, but I'm happy to do a one-off > analysis of your proposed ROAs based on NTT BGP data. Just mail me in > CSV format the prefix, maxlenght, origin asn(s). > > Kind regards, > > Job > -- > RPKI mailing list > RPKI at nlnetlabs.nl > https://www.nlnetlabs.nl/mailman/listinfo/rpki -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at nlnetlabs.nl Thu Feb 28 04:17:13 2019 From: tim at nlnetlabs.nl (Tim Bruijnzeels) Date: Thu, 28 Feb 2019 13:17:13 +0900 Subject: [RPKI] Potential for test/dev trust anchor? In-Reply-To: <09BD68AC-9191-425F-975B-C822525E2F39@nlnetlabs.nl> References: <23667.20633.692740.803813@oz.mt.att.com> <8964245e-c0cf-b182-9fd2-594e115d1c41@blargh.com> <20190225030354.GD32301@vurt.meerval.net> <09BD68AC-9191-425F-975B-C822525E2F39@nlnetlabs.nl> Message-ID: <2C6CCD6F-0F08-4C9A-866F-C7927F50602D@nlnetlabs.nl> Hi all, And to be clear... this is in the readme as well You can of course feed it hypothetical data if you want to simulate and see the outcome - but you will need to stick to the format of the files, and use a value of 5 or higher for the number of peers that 'saw' the announcement. For invalids/unseens you do not need the NRO stats. Tim > On 27 Feb 2019, at 16:49, Tim Bruijnzeels wrote: > > Hi, > > This may help: > https://github.com/NLnetLabs/secure-routing-stats > > This is a small stand-alone (rust-based) tool that can combine ROAs (Validated ROA Payloads) from a routinator csv output, with RIS style aggregated BGP dumps and NRO stats for: > * global ROA quality stats > * invalids for address space X, Y, Z > * unseen (stale?) ROA VRPs for address space X,Y,Z > > Tim > >> On 25 Feb 2019, at 12:03, Job Snijders > wrote: >> >> On Sun, Feb 24, 2019 at 07:59:09PM -0700, Andrew Gray wrote: >>> On 2/24/2019 7:19 PM, Jay Borkenhagen wrote: >>>> Andrew Gray writes: >>>>> [...] Could a dev/testing >>>>> trust anchor be set up by the community, and have a couple of the tier 1 >>>>> providers provide feedback from that through one of the various looking >>>>> glass systems? >>>>> >>>>> This would allow people to use that test trust anchor to verify they >>>>> have advertisements correct, things do what they want, etc., before then >>>>> pulling the advertisement over to whichever RIR is appropriate for >>>>> production work. >>>>> >>>> >>>> That sounds like a job for your RP software. >>>> >>>> For example, RIPE's rpki-validator-3 allows its operator to configure >>>> whitelist entries. After configuring a whitelist entry -- which is in >>>> essence a local ROA -- the RIPE software will show which current >>>> routes known to RIPE RIS would be validated or invalidated by the >>>> whitelist ROA. >>> >>>> If that kind of 'what if?' analysis is important to you, you should >>>> tell your favorite RP project. (For my money, it's OK to have this, >>>> but other RP features / capabilities are more important to me.) >>> >>> This thought was based on some of the comments heard both at the RPKI >>> gathering and at NANOG afterwards - people are very leery of deploying ROA >>> objects at all for fear of what will happen because of those announcements. >>> Telling operators that "If you do nothing, the worst that will happen is >>> you're subject to prefix hijacks. If you do deploy this and have it wrong, >>> you drop your company/ISP/what-have-you off the internet which is almost >>> certainly a Resume Generating Event" is an extremely hard sell for network >>> engineers to make to their management. Giving them more tools to validate >>> things are correct in a trivial to look at and for management to see format >>> would be valuable. >>> >>> I guess the root thought is - how can this level of validation made as easy >>> and low-impacting as possible? The desire is to have a great many people >>> sign their assignments - the fewer barriers/software needs/etc. in the way >>> the better. >> >> I don't know if it is of any help, but I'm happy to do a one-off >> analysis of your proposed ROAs based on NTT BGP data. Just mail me in >> CSV format the prefix, maxlenght, origin asn(s). >> >> Kind regards, >> >> Job >> -- >> RPKI mailing list >> RPKI at nlnetlabs.nl >> https://www.nlnetlabs.nl/mailman/listinfo/rpki > -- > RPKI mailing list > RPKI at nlnetlabs.nl > https://www.nlnetlabs.nl/mailman/listinfo/rpki -------------- next part -------------- An HTML attachment was scrubbed... URL: