[ipv6hackers] (IETF I-D); Implications of IPv6 Addressing on Security Operations (Fwd: New Version Notification for draft-gont-opsec-ipv6-addressing-00.txt)

[Henrik Kramselund]

On Fri, 3 Feb 2023 02:05:38 -0300
Fernando Gont <fgont at si6networks.com> wrote:

> Folks,
> 
> I happened to participate in an IPv6 deployment meeting with some
> large content provider. Eventually there was a discussion about how
> to mitigate some attacks using block-lists, and they argued that they
> ban offending addresses (/128 for the IPv6 case), following IPv4
> practices. While they had already deployed IPv6, some of the
> associated implications arising from the increased address space
> seemed to be non-obvious to them.


Hi there

An idea you might want to include, maybe needs expansion or rewording.
Would be happy to work with you.

- you discussed why /128 might not be efficient to block, and
  continuing on that - trying to expand section before 4.2

I think a security engineer with little knowledge of IPv6 would need
more precise information. This also goes for fail2ban - which is one of
the worst tools in the world IMHO.


## Aggregating prefixes used for blocking

A network tool correlating activity might want to present results as
counted and correlated considering common IPv6 prefix sizes. These
might be /64, /56, /48 and even /32 from a large network.

Then when proposing an action for blocking, the network operator is
encouraged to evaluate these sizes in relation to time and ressource
used. 

For instances blocking /128 for a week might be considered appropriate
for a mail server sending bad content. Whereas brute-force attempts
from a network block starting to use multiple, perhaps even 100s or
1000s of entries in a blocking list with /128s would starve ressources
available in blocking and filtering devices.

In the latter case it may be more suitable to block the containing /64
or /48 which might be a single customer, or site. The actual result may
vary but turning away the unwanted traffic is a decision made by the
receiver. In the case where so much traffic is received from a /32
prefix blocking the whole network might be harsh and should perhaps
only be considered for a shorter time.

Example
Brute force login attacks are received over TCP from a single IPv6
source address /128. This confirms the system is sending unwanted
traffic and the source is not spoofed. The address is added to a
filtering ACL permanently - until some future cleanup.

Later, more unwanted traffic of the same sort is received matching the
same /64. When this crosses some limit, say 10 the filtering ACL is
updated with a /64 replacing the entries of size /128. This entry is
scheduled for removal within a week.



## Historical archiving of prefixes which have been blocked 

We may also recommend that systems built to filtering and block IPv6
prefixes save the information for future use.





Note: maybe also a table of sorts, lining up the "common sizes" with
reference to the previous addressing RFCs which gave the
recommendations for a "customer" "network" etc. - as it seems the
operators you talked to did NOT know these common sizes.






-- 
Mvh/Best regards

Henrik
—
Henrik Kramselund, he/him internet samurai cand.scient CISSP
Follower of the Great Way of Unix
hlk at kramse.org hlk at zencurity.dk +45 2026 6000