[ipv6hackers] an interesting DHCPv6 DoS
Tassos Chatzithomaoglou
achatz at forthnet.gr
Tue Feb 4 16:58:45 CET 2014
Mark ZZZ Smith wrote on 04/02/2014 12:50:
>
>> ________________________________
>> From: Tassos Chatzithomaoglou <achatz at forthnet.gr>
>> To: ipv6hackers at lists.si6networks.com
>> Sent: Thursday, 30 January 2014 7:42 AM
>> Subject: [ipv6hackers] an interesting DHCPv6 DoS
>>
>>
>> Each DHCPv6 binding includes a different prefix due to the different DUID, but the client is always the same.
>>
>> Client: FE80::A16A:B735:8C29:63E9
>> DUID: 000100011A782CB8000000000000
>>
>> Client: FE80::A16A:B735:8C29:63E9
>> DUID: 000100011A782CB9000000000000
>>
>> Client: FE80::A16A:B735:8C29:63E9
>> DUID: 000100011A782CBB000000000000
>>
>> Client: FE80::A16A:B735:8C29:63E9
>> DUID: 000100011A782CBC000000000000
>>
>> Client: FE80::A16A:B735:8C29:63E9
>> DUID: 000100011A782CBE000000000000
>>
>> Client: FE80::A16A:B735:8C29:63E9
>> DUID: 000100011A782CBF000000000000
>>
>> ...
>>
>>
>> The issue is triggered by the CPE asking for IA-NA & IA-PD, while only IA-PD is available.
>> Although the DHCPv6 server answers with NOADDRS-AVAIL to the IA-NA, the CPE thinks it is smarter and asks again for IA-NA using a new DUID...and it continues doing so for many hours, until all its DUIDs are exhausted...or all the DHCPv6-PD prefixes are exhausted
>>
>> We have seen up to 3k bindings per hour from a single CPE!
>> We have informed both the CPE (TP-Link) and DHCPv6/BRAS (Cisco) vendors of the issue and we are hoping for a solution.
>> As it seems, nobody at Cisco thought of giving the capability to limit the number of bindings on a DHCPv6 server based on something different than the DUID.
>>
> Not to dismiss the possibility of a DoS via this method, however that CPE is behaving really badly. It should be using the same DUID for each request, as required in RFC6204/RFC7084,
>
> W-5: The IPv6 CE router MUST use a persistent DHCP Unique Identifier
> (DUID) for DHCPv6 messages. The DUID MUST NOT change between
> network-interface resets or IPv6 CE router reboots.
>
> and the DHCPv6 RFC, RFC3315,
>
>
> "The DUID is
> designed to be unique across all DHCP clients and servers, and stable
> for any specific client or server - that is, the DUID used by a
> client or server SHOULD NOT change over time if at all possible; for
> example, a device's DUID should not change as a result of a change in
> the device's network hardware."
>
> Trusting any attribute the DHCPv6 client supplies as an identifier would be vulnerable to this sort of problem, unless DHCPv6 authentication is used, or some other network attribute such as circuit ID rather than any CPE supplied attribute is used to uniquely identify the client.
All these are probably known to the CPE vendors, although i don't feel sure they follow them to the letter.
What i'm trying to say is that regardless of what a CPE is doing, your network should be able to cope with every possible scenario, good or bad.
We shouldn't write software that expects everyone to behave according to "rules".
>
> One other question though, it also shouldn't be asking for a IA-NA unless you have the M bit (Managed Address bit) switched on in RAs. If you do have it switched on, it would be interesting whether switching it off (just leaving the O bit switched on) would stop the CPE asking for IA-NAs in its DHCPv6 requests.
M is off, only O is on.
It's the only CPE (based on the customers' feedback) that shows such a behavior.
--
Tassos
More information about the Ipv6hackers
mailing list