On Fri, 2019-11-01 at 07:09 +0100, Job Snijders wrote: > On Fri, Nov 01, 2019 at 01:23:44AM +0000, Job Snijders wrote: > > On Thu, Oct 31, 2019 at 09:42:21PM +0100, Gert Doering wrote: > > > On Thu, Oct 31, 2019 at 07:10:02PM +0000, Job Snijders wrote: > > > > 1/ What is the ROI? I think there is only a few prefixes in the > > > > default-free zone that are managed by RIPE NCC, but not > > > > assigned or > > > > allocated by RIPE NCC. So putting this machinery in place might > > > > not > > > > have that much benefit, while the cost of 'getting it wrong' > > > > could > > > > be substantial. > > > > > > This was my first thought as well, but then I discovered this > > > IPv6 > > > thing :) > > > > Other than that there is lots of unassigned space in IPv6, and no > > shortage, what is the relevance? Did you take a look at how many > > unassigned/unallocated IPv6 prefixes (managed by RIPE NCC) are > > actually > > in the DFZ? > > I ran the numbers, as far as I can tell we only have a handful of > IPv6 > prefixes in the default-free zone that are RIPE NCC managed space, > and > in the 'reserved' category (looked at today's delegated-latest) > The issue for me is not that there are many such prefixes sitting in the DFZ in steady state, but that as part of attack-prep they can be stood up to defeat loose-urpf-based anti-spoofing mechanisms.
We currently mitigate this using the team cymru bgp service, which has two primary drawbacks: 1. the dependency on the underlying transport of the multihop bgp session 2. the implicit trust that we place in TC (however merited) to make assertions about the status of the address space. The current proposal solves #2 outright. #1 would only be partially solved, given that we would still rely on connectivity between our validation caches and the ripe publication endpoints. However, this should be far less fragile in the face of short-term reachability issues than a bgp session. I still support. Cheers, Ben
