Hi,
On 8/4/24 12:49 PM, Gert Doering wrote:
Not really. Do the math. In v4, even if you change your IP, the amount
of addresses a single bad actor has available is always small - while
in v6, inside a single /64 subnet, the number of addresses is obviously
vastly beyond what you can store in a blocklist.
I do the math. Bad actors - even in SoHo environment - can easily get
/48, that means 65k subnets. And bad actor can be of course whole LIRs
holding /29... which can be fragmented and distributed around the globe
from routing perspective to make identification difficult. Merges and
acquisions are complicating this further, and we get to really big
numbers, where /64 is only.... a drop in the sea. But still... this is
whole LAN segment and we should keep this in our minds.
For some reason, NCC decide to start with /64 here, not with /128... and
this simply penalizes IPv6 users compared to those who are IPv4-only.
That's like throwig out the baby with the bathwater - you always block
whole LAN on IPv6, not only single host (happens on IPv4 initially).
OTOH it would make sense to follow a staged approach here - for the first
hit, block the /128, and if there are more than <threshold> hits in a
/64, block the whole /64.
Yes, that's exactly what I'm looking for. Staged approach, block /128,
then /64... and then granularry larger subnets (up to allocation).
This would cover "single host errors" while at the same time protecting
the RIPE DB from intentional abuse.
This will be always hard. Motivated bad actors can use for example some
short-living machines, many suppliers provide even API for this and
sourrce addresses can change really fast... and that's only the first
thing that came to mind. I'm not saying not to fight this.
In my case, I also missed any notification about "malicious" activity to
registered abuse contact. I think this should be part of process in case
at least when subnet (more than single host) is blocked. Automatically
generated notification is sufficient here. I think is good to know about
such issues from network-operator perspective. Even if it will be an
opt-in (but I think good operator takes care about similar events in its
network).
- Daniel
-----
To unsubscribe from this mailing list or change your subscription options,
please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings.
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
