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

[Andrew Ruthven]

On Sat, 2023-02-04 at 23:45 -0300, Fernando Gont wrote:
> >     - Now let me be general in this second point.  I think there is
> > a
> >     big piece missing in this document, and that is what are the
> > correct ways
> >     of thinking when it comes to these scenarios with IPv6.  you
> > certainly hint
> >     at them, and for those who have implemented IPv6 in firewalls,
> > we get where
> >     you are going, but the problem is you really never get to the
> > end game in
> >     this draft.  Perhaps that was your intent, so that future
> > drafts would add
> >     the necessary detail.
> 
> Do you mean, e.g., that the draft should e.g. provide advice such as
> "do 
> not block a single /128, bur rather consider blocking a /64 at a 
> minimum", and the like? or something else?

I suggest having provisions to escalate from /128 to /64 to /56 to /32
rather than jump directly to /64.

The reason for this is that there may still be legitimate users in that
/64. We experienced this painfully at work where the IRC daemon we used
to use had built in, hardcoded connection ratelimiting. For IPv4 it was
per IP, for IPv6 it was per /64. Everyone connecting at the start of
the work day would trip the ratelimiting...


Cheers,
Andrew

-- 
Andrew Ruthven, Wellington, New Zealand
andrew at etc.gen.nz |
Catalyst Cloud: | This space intentionally left blank
https://catalystcloud.nz |