[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]

Hey,

On Tue, 2023-02-07 at 01:07 -0300, Fernando Gont wrote:
> On 5/2/23 00:38, Andrew Ruthven wrote:
> [....]
> > > 
> > > 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.
> 
> mmm... but in your list, there's no middle-ground between /128 and
> /64.

Is there any sensible middle ground between a /128 and /64? I can just
pick whatever IP I want within that /64. And if privacy addresses are
being used, they'll move around anyhow.

Perhaps apply a mask to be able to reject privacy addresses within a
/64?

The benefit I can see to starting with blocking /128s is it'll stop
opportunistic people or some beginner script kiddies. But I think once
you hit X /128s within a /64, then you block the /64. I don't know what
X is, most like site dependant.

> > 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...
> 
> What kind of rate-limiting?

Hah, they still do it.

https://github.com/UndernetIRC/ircu2/blob/master/ircd/IPcheck.c#L119

If there are too many connection attempts to the IRC daemon from a
single /64, then additional connections will be blocked until the
timeout expires. Hardcoded.

Cheers,
Andrew

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