Re: [v6ops] preventing denial of service in IPv6

["Ray Hunter (v6ops)" <[e-mail]>]

inline.

> Metzler, Dan J <mailto:[e-mail]>
> 25 Nov 2015 16:09
>
> With regard to the notion that IPv6's large (source) address space
>
> "...also gives attackers a potential advantage over defenders w.r.t. 
> resource depletion attacks compared to the scarcity of source 
> addresses in IPv4"
>
> I mentioned this before, so don't want to dwell on it too much, but 
> think it is important to understand the problem from a real world 
> perspective.  An address does not deplete resources.  It takes an 
> interface with CPU and memory to do that.
>
> "If an attacker compromises an important server in a corporate 
> network, and the corporation have been sloppy and only applied BCP38 
> egress filtering at the external boundary at /32 level (rather than 
> individual filters at each /64 per LAN) that could form a very 
> attractive attack platform (2^32/2^64 potential /64 prefixes = 
> equivalent to the entire current Internet address space sourced from a 
> single machine)."
>
> The important point is, with regard to resource depletion, this is a 
> still single machine, and in the context of DOS attack platforms, is 
> usually insignificant without additional systems from which to launch 
> the attack.  Indeed utilizing that many addresses during an attack 
> carries with it some significant overhead that would take away from 
> the effective throughput in this scenario.
>
> The real concern in the stated scenario is the randomly changing 
> source addressing that might evade detection other than the fact that 
> it is all coming from the same subnet.  (That in itself ought to be a 
> useful clue for the corporate network admins of the compromised 
> system, if they are looking to detect the issue.)
>
But if the BCP38 filtering is "weak" then the notion of 'subnet' is lost 
to the outside world.

I hope that rack space providers have good filtering (at subnet/machine 
level).

In the past there was an automatic upper limit for source addresses 
based on the assigned address space, even if BCP38 filters were lax at 
the subnet level.
>
> When we think about this from a comparison to IPv4, the change is not 
> in the amount of resources that can be dedicated to the attack, but in 
> the potential identities from which they are sourced.
>
Agreed.
>
> Certainly the massive address space could lead to significant 
> abilities to attack other systems, but it requires more than just 
> address space.  It requires a corresponding investment in network 
> throughput and endpoints that can initiate the attack.
>
I disagree here.

The tracking mechanisms in many current firewalls and other devices rely 
on tracking by remote identity = IPv4 source address.

Even with 10gbps connectivity at the attackers end, a single attacking 
machine could easily be identified, tracked, and blocked before much 
traffic hit end hosts at say 1Gbps or 100Mbps.

In IPv6, Identity and state now needs to be tracked at multiple levels 
of prefix length.

Otherwise the tracking mechanisms or NAT slots or load balancing slots 
or state tables in your firewalls or other middleware box become the 
attack target for resource depletion (exhaustion of tracking slots in 
the middleware box).

Which means IMHO that any state-based middleware boxes are potential 
targets.
[yes, I know the IETF denies these devices exist]

The same is true for the identity slots in any peer to peer network that 
relies on remote IP address = peer identity.
These peer tables can now be poisoned by a single machine filling up the 
peer table with garbage.

That resource depletion attack was not easily feasible in IPv4, because 
of source address scarcity.

A single attacker could not trivially overflow the peering table of 
multiple torrent clients by sending just a few packets.

So IMVHO this is a new attack vector. Or at least one that has greatly 
reduced in how difficult it is to execute.
>
> While we think about these issues, I think it is important to not lose 
> sight of that.
>
> Thanks,
>
> -Dan
>
> *From:*Ray Hunter (v6ops) [mailto:[e-mail]]
> *Sent:* Wednesday, November 25, 2015 8:12 AM
> *To:* Nikos Mavrogiannopoulos <[e-mail]>
> *Cc:* Metzler, Dan J <[e-mail]>; [e-mail]
> *Subject:* Re: Re: [v6ops] preventing denial of service in IPv6
>
>
>
> Nikos Mavrogiannopoulos wrote:
>
>       
>
>     Then a single user can exhaust a server's resources by simply
>
>     attacking the server with all his available addresses.
>
>
> FWIW I agree with the original premise that IPv6's large (source) 
> address space is a blessing, but also gives attackers a potential 
> advantage over defenders w.r.t. resource depletion attacks compared to 
> the scarcity of source addresses in IPv4.
>
> I think the problem here is that attackers may also have access to a 
> /32 .. /48 /52 /56 or /60, as well as /64.
>
> If an attacker compromises an important server in a corporate network, 
> and the corporation have been sloppy and only applied BCP38 egress 
> filtering at the external boundary at /32 level (rather than 
> individual filters at each /64 per LAN) that could form a very 
> attractive attack platform (2^32/2^64 potential /64 prefixes = 
> equivalent to the entire current Internet address space sourced from a 
> single machine).
>
>
>       
>
> -- 
>
> regards,
> RayH
>
> Ray Hunter (v6ops) <mailto:[e-mail]>
> 25 Nov 2015 15:12
>
>
> Nikos Mavrogiannopoulos wrote:
>> On Fri, Oct 23, 2015 at 3:18 PM, Metzler, Dan J<[e-mail]>  wrote:
>>
>>>> So one would expect software to blacklist
>>>> whole ranges of networks, e.g., a /64 or /48 once few IPs violate some of its
>>>> "detection properties".
> Agreed.
>>> [DJM] I would think one would expect software to block a single IP address for IPv6 in the same scenarios where that would happen in IPv4.
>>> Granted IPv6 makes it a bit easier to repeatedly change addresses, purely from an availability standpoint, in the same way that it makes it a bit harder to scan addresses.
>>> I would expect blocking a /64 to be the equivalent of blocking a subnet in IPv4, because it is.
>>
>> Then a single user can exhaust a server's resources by simply
>> attacking the server with all his available addresses.
>
> FWIW I agree with the original premise that IPv6's large (source) 
> address space is a blessing, but also gives attackers a potential 
> advantage over defenders w.r.t. resource depletion attacks compared to 
> the scarcity of source addresses in IPv4.
>
> I think the problem here is that attackers may also have access to a 
> /32 .. /48 /52 /56 or /60, as well as /64.
>
> If an attacker compromises an important server in a corporate network, 
> and the corporation have been sloppy and only applied BCP38 egress 
> filtering at the external boundary at /32 level (rather than 
> individual filters at each /64 per LAN) that could form a very 
> attractive attack platform (2^32/2^64 potential /64 prefixes = 
> equivalent to the entire current Internet address space sourced from a 
> single machine).
>
> I wrote some (experimental) code last year in C to track source 
> addresses using a Patricia Tree. I intended to use this in front of 
> our mail server, but never got around to implementing it. I can share 
> if you want.
>
> My experiments suggested that it was best to track sessions was using 
> a 4 bit nibble to key each branch of the Patricia tree, and then 
> initiate a firewall block at this level if there were above a 
> threshold number of sessions from a given prefix length in a given 
> time (more experimentation needed to determine the thresholds in 
> operation to avoid false positives). I did not find that tracking 
> beyond /64 was worthwhile, given the impossible task of distinguishing 
> between a legitimate temporary address, or a hand configured /127. 
> Using an octet at the tree branch vastly increased memory usage. Using 
> a binary tree increased search time (64 recursive lookups rather than 
> 16 to track to /64 level).
>
> The code could track large numbers of connections per second, at the 
> expense of eating up to 2GB of memory for the tree structure to track 
> several million connections.
>
> An alternative would be to add this prefix-length-aware triggering 
> into a log follower like fail2ban.
>
> Whether this is a good/viable defence strategy remains to be proven.
>
>>>> Given recommendations like RFC6164 which
>>>> recommend /127 for PtP links (which can be a user VPN link), any heuristic
>>>> that will ban whole networks looks more like a vessel to perform another
>>>> denial of service (e.g., denying some user access to a server), rather than a
>>>> solution to the original denial of service.
>>> [DJM] Absolute agreement here, as is the case with IPv4.
>>> A better approach would be to intelligently and dynamically block offending individual addresses, or sets of addresses, based off of more information than a simple assumption that if there is one offender on a subnet, then they all must be offenders.
>>> Of course one might want to block a whole subnet once some sort of critical threshold was reached of a certain number of offending IPs on that subnet.
>>>
>>>> This is further reinforced by the fact
>>>> that smaller than /64 networks are occasionally handed out by ISPs to their
>>>> users.
>>>>
>>>> Are there any recommendations for protecting servers from the IPv6 address
>>>> proliferation?
>>> [DJM] Address proliferation doesn't seem like a vulnerability to protect against.
>>> I think that would be deviating from the problem; the DOS attack.
>>> DOS is largely a game of resources; attempting to allocate a large enough pool of resources, that participate in a DOS attack, so as to exceed the capacity of the finite resources dedicated to handling a load.  The fact that the resources instigating the attack has a larger pool of addresses, to use, doesn't change the amount of resources participating in the attack, or the number of addresses in use at a given point in time.
>>> Also, the likelihood that a DOS attack would be  sourced entirely from a single subnet seems more and more of an edge case as time goes on.  (If it were only that easy.)
>>
>> IPv6 makes that easy. In IPv4 DOS attacks don't come from a single
>> subnet because it is expensive to obtain control of a big subnet. In
>> IPv6 you get 2^64 addresses just like that.
>>
>>>> If not, are there any conventions for IPv6 address assignment
>>>> to end-users?
>>> [DJM] Outside of the typical DHCPv6 and SLAAC?
>>
>> Could you elaborate what on that? I know that SLAAC requires /64 to
>> operate, but I'm not aware of any conventions for DHCPv6.
>>
>> regards,
>> Nikos
>>
>>
>

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>