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

[Fernando Gont]

Hi, Andrew,

On 7/2/23 02:26, Andrew Ruthven wrote:
> 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?

What I meant is that there seemed to be a bug in your original sentence.
" I suggest having provisions to escalate from /128 to /64 to /56 to /32 
rather than jump directly to /64."

-- i.e., not sure what you mean't by "jumping directly to /64".


> ican 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?

Not possibly. It's impossible (by design) to tell RFC7217 vs RFC8981.



> 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.

Yes. That's what we mean (at least) in our document.


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

Thanks for the pointer -- it will make for a useful reference in our 
document.

That said, what they do is valid -- the devil is in the tuning.  -- 
i.e., you can't really tell multiple different users in a /64 vs. a 
single using controlling/using the whole /64....



> 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.

The "hardcoded" bit is where the flaw lies, probably.

Thanks!

Regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494