In the old days of DOCSIS, I was able, during failures of DHCP (for
various reasons) to self assign a "nearby" IP address in the same subnet
and this worked fine as long as that IP wasn't being used by someone
else at the time.
While this was done to cope with some failures or bad policy at the
cable company with no ill intent, I realise that I could have used this
technique to do bad stuff on the internet with DHCP logs pointing to
some neighbour (or poiting to nothing).
Has this "loophole" been plugged with the advent of DOCSIS2 and now
DOCSYS3 software ? Or is DHCP still just a "suggestion" of what IP to
use, with ARP being the authoritative mechanism used by the CMTS to know
the MAC address associated with an IP address ?
If this has been solved, at what level was it done ? is it the DOCSYS
modem that sets up a filter based on a DHCP response to only let traffic
"from" the assigned IP address through ? Or would it be done at the
CMTS (again based on the DHCP response being recorded) ?
I ask this in the context of the law where one party tries to sue
another based on IP address (such as Voltage Pictures suing thousands of
IP addresses). If B can use the IP address that DHCP assigned to A and A
gets sued, it becomes rather difficult to prove.
Many thanks. In particular, you need "cable-source-verify dhcp" to
prevent self assigned IPs that are unused by neighbours.
Is this something that is now basically a default for all cable
operators ? Or does this command add sufficient load to the CMTS that
some cable operators choose to not use it for performance purposes ?
What happens when a CMTS reboots and has an enpty database of DHCP
leases ? Does it then query the DHCP server for every IP/MAC it sees
that it doesn't yet know about ?
Many thanks. In particular, you need "cable-source-verify dhcp" to
prevent self assigned IPs that are unused by neighbours.
Is this something that is now basically a default for all cable
operators ? Or does this command add sufficient load to the CMTS that
some cable operators choose to not use it for performance purposes ?
Nobody would turn it off for that reason. They might fail to turn it on if they didn't read best practices for at least 10 years. It's pretty much part of a fundamental set of commands turned on to prevent cable modem theft (along with requiring BPI+ and other things)
Here's an article I just found searching for "docsis bpi+"
http://volpefirm.com/blog/security/hacking-docsis-cable-modems/
What happens when a CMTS reboots and has an enpty database of DHCP
leases ? Does it then query the DHCP server for every IP/MAC it sees
that it doesn't yet know about ?
Most of the time when a CMTS reboots they don't even get to the point of failing due to DHCP issues. In any case the CMTS would ask the DHCP server and be happy with it's reply since it's the equivalent of a new modem coming online.
Most of the time the modems would fail into reject(pk) due to the public key negotiation not being valid now that the CMTS has been rebooted. To fix that you could either wait for the modems to try again or run "clear cable modem reject delete" if it's a Cisco CMTS.