[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
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.
So that's what motivated the publication of this document.
* TXT:
https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-addressing-00.txt
* HTML:
https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-addressing-00.html
Comments welcome!
Thanks,
Fernando
-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-opsec-ipv6-addressing-00.txt
Date: Thu, 02 Feb 2023 19:48:40 -0800
From: interne...@ietf.org
To: Fernando Gont <fg...@si6networks.com>, Guillermo Gont
<gg...@si6networks.com>
A new version of I-D, draft-gont-opsec-ipv6-addressing-00.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.
Name: draft-gont-opsec-ipv6-addressing
Revision: 00
Title: Implications of IPv6 Addressing on Security Operations
Document date: 2023-02-02
Group: Individual Submission
Pages: 8
URL: https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-addressing-00.txt
Status: https://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-addressing/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-gont-opsec-ipv6-addressing
Abstract:
The increased address availability provided by IPv6 has concrete
implications on security operations. This document discusses such
implications, and sheds some light on how existing security
operations techniques and procedures might need to be modified
accommodate the increased IPv6 address availability.
The IETF Secretariat
_______________________________________________
Ipv6hackers mailing list
Ipv6h...@lists.si6networks.com
https://lists.si6networks.com/mailman/listinfo/ipv6hackers
Henrik Kramselund
Fernando Gont <fg...@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
h...@kramse.org h...@zencurity.dk +45 2026 6000
Andrew Walding
There is a typo in Section 4.1 I think (sunch instead of such).
.
A couple of general comments.
I think this is a good subject and one that probably needs guidance as this
document suggests. That said, I have the following thoughts:
- I will start by being a bit picky. I think the wording describing the
issues is spread too vaguely and needs to be more specific as to the
addressing issues. For example in your email you say compared to IPv4
where you are usually dealing with "an" address from a private or public
network, but in IPv6 a given host could have multiple addresses in multiple
prefixes/networks then compounded with the various address types of IPv6,
yet this is muddled in the document itself. I mean that is the point in
the end - you cannot deal with IPv6 the same way you deal with IPv4 in this
security scenario.
- 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.
Anyway, I hope this helps in some way,
Best,
Andy
Markus Reschke
Hi!
> - I will start by being a bit picky. I think the wording describing the
> issues is spread too vaguely and needs to be more specific as to the
> addressing issues. For example in your email you say compared to IPv4
> where you are usually dealing with "an" address from a private or public
> network, but in IPv6 a given host could have multiple addresses in multiple
> prefixes/networks then compounded with the various address types of IPv6,
> yet this is muddled in the document itself. I mean that is the point in
> the end - you cannot deal with IPv6 the same way you deal with IPv4 in this
> security scenario.
be helpful to provide more concrete examples and recommendations.
ciao
Markus
--
/ Markus Reschke \
\ mad...@theca-tabellaria.de /
Fernando Gont
Nice to hear from you! (and thanks for the prompt response!) -- In-line...
On 4/2/23 12:04, Andrew Walding wrote:
> Hi Fernando,
> There is a typo in Section 4.1 I think (sunch instead of such).
> .
> A couple of general comments.
> I think this is a good subject and one that probably needs guidance as this
> document suggests. That said, I have the following thoughts:
>
> - I will start by being a bit picky. I think the wording describing the
> issues is spread too vaguely and needs to be more specific as to the
> addressing issues. For example in your email you say compared to IPv4
> where you are usually dealing with "an" address from a private or public
> network, but in IPv6 a given host could have multiple addresses in multiple
> prefixes/networks then compounded with the various address types of IPv6,
> yet this is muddled in the document itself. I mean that is the point in
> the end - you cannot deal with IPv6 the same way you deal with IPv4 in this
> security scenario.
> - 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.
not block a single /128, bur rather consider blocking a /64 at a
minimum", and the like? or something else?
Thanks!
Cheers,
--
Fernando Gont
e-mail: fern...@gont.com.ar
PGP Fingerprint: 7F7F 686D 8AC9 3319 EEAD C1C8 D1D5 4B94 E301 6F01
Andrew Walding
Similarly inline....
guiding light these days. I think this needs to be mentioned as perhaps a
new paragraph 2 in section 1.
Further I would add a paragraph in section1 before that last paragraph that
plainly states:
A well developed experience level with IPv4 addressing and traffic
monitoring/firewalling and security policy development has been ingrained
in network designs. As these networks deploy IPv6 the complexity of
security policies has to expand to consider multicast, global unicast,
unique local, link local, and other address types. In simple terms, you
cannot deal with IPv6 security policies the same way you have dealt with
IPv4.
>
> > - 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?
>
>
if they all apply, but forgive me while I brain dump below.
Implementers may choose to combine some of these example policies. Also
forgive me if I get some details wrong as I am typing this off the top of
my head. Also, since RFC4890 covers ICMP access lists I leave that alone
-but that might be worth mentioning in your draft as a reference.
Example #1: Dealing with Multicast, especially multicast based scans.
This type of access list would be deployed at the border - the WAN
interface towards a service provider from an institution/business/perhaps
even home. Implemented on that WAN interface on the inbound traffic ports:
ipv6 access list blockv6scan
deny ipv6 any fec0::/10 #we should never see any traffic from
this prefix as it was deprecated in RFC3879
deny ipv6 any ff02::/16 #there should never be any link local
scope destination multicast traffic on that WAN interface, except to the
WAN interface itself
permit ipv6 any ff0e::/16 #allow the global scope multicast traffic
deny ipv6 any ff00::/8 #block anything multicast left over
permit ipv6 any any #permit all other ipv6 traffic
Example #2: Dealing with Unique Local Addresses RFC4193 on the WAN
interface. Even though some of this address space is technically not to be
used per RFC guidance, most router platforms fully support the FC00::/8 and
FD00::/8 address space. It is likely that we should never expect ULA
traffic going out to the global addressing space.
ipv6 access list blockv6ula
deny ipv6 any fd00::/8 #we should never see any traffic going to
the fd00::/8 coming from the WAN interface
deny ipv6 any fc00::/8 #we should never see any traffic going to
the fc00::/8 coming from the WAN interface
permit ipv6 any any #permit all other ipv6 traffic
Example #3: Dealing with Documentation Address prefix RFC3849. Even
though this address space is technically not to be used per RFC guidance,
most router platforms fully support the 2001:0DB8::/32 address space. It
is likely that we should never expect sources or destination addresses
using this prefix anywhere in the network.
ipv6 access list blockv6doc
deny ipv6 any 2001:0db8::/32 #we should never see any traffic
going to the doc prefix
deny ipv6 2001:0db8::/32 any #we should never see any traffic
coming from the doc prefix to any ipv6 destination
permit ipv6 any any #permit all other ipv6 traffic
Example #4: Dealing with IPv6 mapped IPv4 addresses. It is likely that we
should never expect sources or destination addresses using this prefix
anywhere in the network. Service providers will want to be cautios here is
they have deployed 6PE in MPLS networks.
ipv6 access list blockv6mapv4
deny ipv6 any ::ffff/96 #we should never see any traffic going to
the mapped prefix
deny ipv6 ::ffff/96 any #we should never see any traffic coming
from the mapped prefix to any ipv6 destination
permit ipv6 any any #permit all other ipv6 traffic
Example #5: Dealing with an intrusive or misbehaving ipv6 source. The
tendency here is to create either a whitelist or blacklist collection of
allowed or banned addresses. In an IPv4 network this is relatively
straight forward as an interface most likely has only one address.
Further, it does not matter whether the source is a server or client, in
the IPv4 space these addresses tend not to change. In IPv6 this could also
be the case, however there are further considerations.
5-1: If it is a source that has a single Global Unicast Address, first it
is likely a server, though some clients may also follow this single address
deployment, then the full /128 bit address must be added to the
blocked/banned list.
5-2: if the source has deployed RFC4941/RFC8981 then it may use multiple
random IID's over time - it is likely to not be a server. Most temporary
addresses are used for outgoing communications and stable addresses are
used for incoming communications. With any given /64 prefix having 18
quintillion possible IID's, there are two possible problems. 1) Choosing to
ban the entire prefix may ban legitimate sources/destinations in that
prefix including the misbehaving source, or 2) choosing to ban the
additional temporary addresses generated by the interface greatly increases
the size of the blacklist (it should be noted here that most operating
systems that support these RFC's generate at most 4 additional temporary
addresses so best case this is a 4x problem, and with that said it can be
expected that there will be settings and scripts that will alter this
default OS behavior to generate perhaps hundreds). One approach would be
to allow up to some number of individual addresses into the blocked list,
and once that threshold is reached, the /64 prefix is then banned.
5-3: if the source has deployed RFC7217, the source is generating an
unpredictable but stable IID. It is not possible to reverse engineer the
function even though the prefix is known, the other three components will
not be known. Like the temporary address manipulation, the generation of
multiple RFC7217 addresses is possible. We are left with the same two
problems as described in 5-2.
5-4: EUI64 - not sure if a special case is needed for the FFFE IID
format, or any IID format for that matter. If the attacking host is
changing prefixes, and they use the fixed EUI64, it may be possible to
create a policy that blocks that EUI64 IID. Again so few ipv6 hosts use
this anymore I am not sure it is necessary. This is a fringe example.
Example #6: Protocol 41 traffic. This is IPv6 inside IPv4 traffic. A
network manager must decide if this traffic is going to be allowed. This
includes ISATAP, 6to4, 6rd and other tunnelled IPv6 traffic types.
Example #7: If NAT64/DNS64 is deployed, then specific permit statements
need to be added to policies to allow the WKP 64:ff9b::/96 and whatever NSP
prefixes are selected, along with IPv4 address ranges configured into the
NAT system.
I think example 5 was where the main thrust of your draft was headed, and
perhaps I have overstepped your boundaries, if so forgive me. Certainly
there is room in example 5 to be even more specific. Also readers of this
email, if you have windows machines you can view these ipv6 addresses with
the following commands:
- netsh int ipv6 show join #this command will show all ipv6
multicast address groups each of your interfaces has joined.
- netsh int ipv6 show address #this command will show what ipv6
addresses (dhcp, public, temporary, other - Microsofts names) are assigned
to each interface. No multicast info.
- ipconfig #yup that will do the same as the command above, as well
as show ipv4 config. Also no multicast info.
Fernando Gont
In-line....
On 5/2/23 05:18, Andrew Walding wrote:
>>
>
> Most network security folks have adopted the "zero trust" formula as their
> guiding light these days. I think this needs to be mentioned as perhaps a
> new paragraph 2 in section 1.
>
> Further I would add a paragraph in section1 before that last paragraph that
> plainly states:
>
> A well developed experience level with IPv4 addressing and traffic
> monitoring/firewalling and security policy development has been ingrained
> in network designs. As these networks deploy IPv6 the complexity of
> security policies has to expand to consider multicast, global unicast,
> unique local, link local, and other address types. In simple terms, you
> cannot deal with IPv6 security policies the same way you have dealt with
> IPv4.
[me thinking out loud, more than arguing against]
I'd be skeptical in e.g., mentioning multicast or e.g. link-local
addresses, since that seems to be more of a general firewalling issue
than an IPv6-addresss ACL one.
e.g., there's multicast in IPv4, too. It just happens that in IPv6,
multicast is employed even fore regular and core functionality such as
Neighbor Discovery.
>> 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?
>>
>>
> Well not exactly. Here are some example policies I can think of - not sure
> if they all apply, but forgive me while I brain dump below.
> Implementers may choose to combine some of these example policies. Also
> forgive me if I get some details wrong as I am typing this off the top of
> my head. Also, since RFC4890 covers ICMP access lists I leave that alone
> -but that might be worth mentioning in your draft as a reference.
>
[...]
As noted above, these are indeed valid, but it seems to go beyond the
(at least original) scope of this document. Our original intent was to
discuss how security operations involving IP addresses conceptually
change. e.g.:
* If you want to allow incoming connections from a specific host, beware
of temporary addresses which will result in the same host regularly
changing its addresses -- therefore, either disable temporary addresses
or specify the allow list as a /64.
* When configuring block-lists, please note that IPv6 attackers will
typically control way more than a /64 -- hence the granularity of
block-lists should be the same... or otherwise a skilled attacked could
easily circumvent such block-lists.
That said, it probably does make sense to mention e.g., the multiple
prefixes a host may employ, since it might be a "gotcha" that folks
configure e.g. an allow-list for one prefix (e.g. global prefix in a
private network) but the source address selection rules causes the host
to choose a different source prefix/address and hence the ACL fails.
> Example #2: Dealing with Unique Local Addresses RFC4193 on the WAN
> interface. Even though some of this address space is technically not to be
> used per RFC guidance, most router platforms fully support the FC00::/8 and
> FD00::/8 address space. It is likely that we should never expect ULA
> traffic going out to the global addressing space.
> ipv6 access list blockv6ula
> deny ipv6 any fd00::/8 #we should never see any traffic going to
> the fd00::/8 coming from the WAN interface
> deny ipv6 any fc00::/8 #we should never see any traffic going to
> the fc00::/8 coming from the WAN interface
> permit ipv6 any any #permit all other ipv6 traffic
As with some of the above, this one seems to fall more into a general
firewalling issue (bogon filtering, so to speak). -- but it might be
sensible to cover this in this document -- particularly if thereś no
other document that covers this.
-- I will certainly raise this question to the opsec wg
(https://datatracker.ietf.org/wg/opsec/about/) , where this document is
targeted.
> Example #5: Dealing with an intrusive or misbehaving ipv6 source. The
> tendency here is to create either a whitelist or blacklist collection of
> allowed or banned addresses. In an IPv4 network this is relatively
> straight forward as an interface most likely has only one address.
> Further, it does not matter whether the source is a server or client, in
> the IPv4 space these addresses tend not to change. In IPv6 this could also
> be the case, however there are further considerations.
> 5-1: If it is a source that has a single Global Unicast Address, first it
> is likely a server, though some clients may also follow this single address
> deployment, then the full /128 bit address must be added to the
> blocked/banned list.
The question here is: how can you tell if it has a single address? (from
an external pov)
> 5-2: if the source has deployed RFC4941/RFC8981 then it may use multiple
> random IID's over time - it is likely to not be a server. Most temporary
> addresses are used for outgoing communications and stable addresses are
> used for incoming communications. With any given /64 prefix having 18
> quintillion possible IID's, there are two possible problems. 1) Choosing to
> ban the entire prefix may ban legitimate sources/destinations in that
> prefix including the misbehaving source, or 2) choosing to ban the
> additional temporary addresses generated by the interface greatly increases
> the size of the blacklist (it should be noted here that most operating
> systems that support these RFC's generate at most 4 additional temporary
> addresses so best case this is a 4x problem
Given the typical lifetimes in RFC4941, they actually generate up to
seven addresses ("valid lifetime / preferred lifetime")
[...]
> 5-4: EUI64 - not sure if a special case is needed for the FFFE IID
> format, or any IID format for that matter. If the attacking host is
> changing prefixes, and they use the fixed EUI64, it may be possible to
> create a policy that blocks that EUI64 IID. Again so few ipv6 hosts use
> this anymore I am not sure it is necessary. This is a fringe example.
Agreed on this. And in the case of legacy hosts that use EUI64 IIDs,
most likely they implement RFC4941 -- so it's quite unlikely that you´d
see an attacking host roaming around attacking from its EUI64 IID.
> I think example 5 was where the main thrust of your draft was headed, and
> perhaps I have overstepped your boundaries, if so forgive me.
You raise a valid point. It might make sense to expand the scope.
Although in that case, I'm not sure if one would/should just expand the
scope about filtering based on IPv6 src/dst, or also on a per-protocol
type. (i.e., whether you allow/deny a specific src/dst might depend on
whatś the protocol using it... e.g., particularly for the multicast
case). BUt if one gets into that that might be a very different document
(much larger scope).
Still, it's a valid question to pose to the opsec wg.
P.S.: For all those reading this thread, please consider joining the
opsec wg mailing list (https://www.ietf.org/mailman/listinfo/opsec) --
the IETF wg this document is targeted at.
Thanks!
Regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
Markus Reschke
On Sun, 5 Feb 2023, Andrew Walding wrote:
> Example #5: Dealing with an intrusive or misbehaving ipv6 source. The
> tendency here is to create either a whitelist or blacklist collection of
> allowed or banned addresses. In an IPv4 network this is relatively
> straight forward as an interface most likely has only one address.
> Further, it does not matter whether the source is a server or client, in
> the IPv4 space these addresses tend not to change. In IPv6 this could also
> be the case, however there are further considerations.
changing addresses (e.g. Privacy Extensions), but also the tradeoff
between the number of ACL rules and filtering resources available. The
latter also applies to IPv4. Up to some threshold we can put single
addresses into the ACL with minimal impact on performance. However, when
exceeding the threshold we have to aggregate addresses if possible to
counter the performance impact, also creating collateral damage to some
extend (another tradeoff). And by adding IPv6 /128s we would run much
faster into the threshold.
Fernando Gont
THanks for the comments! In-line...
On 5/2/23 13:26, Markus Reschke wrote:
> Hi!
>
> On Sun, 5 Feb 2023, Andrew Walding wrote:
>
>> Example #5: Dealing with an intrusive or misbehaving ipv6 source. The
>> tendency here is to create either a whitelist or blacklist collection of
>> allowed or banned addresses. In an IPv4 network this is relatively
>> straight forward as an interface most likely has only one address.
>> Further, it does not matter whether the source is a server or client, in
>> the IPv4 space these addresses tend not to change. In IPv6 this could
>> also
>> be the case, however there are further considerations.
>
> IMHO, it's not just about a host having multiple IPv6 addresses or
> changing addresses (e.g. Privacy Extensions), but also the tradeoff
> between the number of ACL rules and filtering resources available. The
> latter also applies to IPv4. Up to some threshold we can put single
> addresses into the ACL with minimal impact on performance. However, when
> exceeding the threshold we have to aggregate addresses if possible to
> counter the performance impact, also creating collateral damage to some
> extend (another tradeoff). And by adding IPv6 /128s we would run much
> faster into the threshold.
This is noted in the I-D, though. Is there anything missing?
Thanks!
Regards,
--
Fernando Gont
e-mail: fern...@gont.com.ar
PGP Fingerprint: 7F7F 686D 8AC9 3319 EEAD C1C8 D1D5 4B94 E301 6F01
Andrew Ruthven
> > - 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
and...@etc.gen.nz |
Catalyst Cloud: | This space intentionally left blank
https://catalystcloud.nz |
Fernando Gont
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.
> 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?
Thanks,
--
Fernando Gont
e-mail: fern...@gont.com.ar
PGP Fingerprint: 7F7F 686D 8AC9 3319 EEAD C1C8 D1D5 4B94 E301 6F01
Andrew Ruthven
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
and...@etc.gen.nz |
Catalyst Cloud: | This space intentionally left blank
https://catalystcloud.nz |
_______________________________________________
Fernando Gont
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: fg...@si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494