Cisco has implemented enhancements within Cisco cable modem termination
system (CMTS) products that inhibit certain types of Denial of Service attacks
based on IP address spoofing and IP address theft in Data-over-Cable Service
Interface Specifications (DOCSIS) cable systems. This document describes the
suite of commands that are part of these IP
address security enhancements.
For more information on document conventions, see the
Technical Tips Conventions.
There are no specific prerequisites for this document.
This document is not restricted to specific software and hardware
A DOCSIS Media Access Control (MAC) domain is similar in nature to an
Ethernet segment. If left unprotected, users in the segment are vulnerable to
many types of Layer 2 and Layer 3 addressing based Denial of service attacks.
In addition, it is possible for users to suffer a degraded level of service due
to the malconfiguration of addressing on other user's equipment. Examples of
this could include:
Configuring duplicate IP addresses on different nodes.
Configuring duplicate MAC addresses on different nodes.
The unauthorized use of static IP addresses rather than Dynamic Host
Configuration Protocol (DHCP) assigned IP addresses.
The unauthorized use of different network numbers within a
Incorrectly configuring end nodes to answer ARP requests on behalf of
a portion of the segment IP subnet.
While these types of problems are easy to control and mitigate in an
Ethernet LAN environment by physically tracking down and disconnecting the
offending equipment, such problems in DOCSIS networks may be harder to isolate,
resolve, and prevent due to the potentially large size of the network. In
addition, end users who control and configure Customer Premise Equipment (CPE)
may not have the benefit of a local IS support team to make sure that their
workstations and PCs are not intentionally or unintentionally malconfigured.
The Cisco suite of CMTS products maintains a dynamically populated
internal database of connected CPE IP and MAC addresses. The CPE database also
contains details on the corresponding Cable Modems that these CPE devices
A partial view of the CPE Database corresponding to a particular cable
modem can be viewed by executing the hidden CMTS command show
interface cable X/Y modem Z. Here, X is the line card number, Y
is the downstream port number and Z is the Service Identifier (SID) of the
Cable modem. Z may be set to 0 to view details about all Cable Modems and CPE
on a particular downstream interface. See example below of a typical output
generated by this command.
CMTS# show interface cable 3/0 modem 0
SID Priv bits Type State IP address method MAC address
1 00 host unknown 192.168.1.77 static 000C.422c.54d0
1 00 modem up 10.1.1.30 dhcp 0001.9659.4447
2 00 host unknown 192.168.1.90 dhcp 00a1.52c9.75ad
2 00 modem up 10.1.1.44 dhcp 0090.9607.3831
Note: Since this command is hidden, it is subject to change and is not
guaranteed to be available in all releases of Cisco IOS® software.
In the example above, the method column of the host with IP address
192.168.1.90 is listed as dhcp. This means that the CMTS learned about this
host by watching the DHCP transactions between the host and the service
provider's DHCP server.
The host with IP address 192.168.1.77 is listed with method static.
This means that the CMTS did not first learn of this host via a DHCP
transaction between this device and a DHCP server. Instead the CMTS first saw
other kinds of IP traffic from this host. This traffic could have been web
browsing, email or "ping" packets.
While it may seem that 192.168.1.77 has been configured with a static
IP address, it may be that this host did in fact acquire a DHCP lease, but the
CMTS may have been rebooted since the event and therefore it does not remember
The CPE database is normally populated by the CMTS gleaning information
from the DHCP transactions between CPE devices and the Service Provider's DHCP
server. In addition, the CMTS can listen to other IP traffic coming from CPE
devices to determine which CPE IP and MAC addresses belong to which Cable
Cisco has implemented the cable interface command cable source-verify
[dhcp]. This command causes the CMTS to make use of the CPE database to verify
the validity of IP packets the CMTS receives on its Cable interfaces and allows
the CMTS to make intelligent decisions about whether to forward them or not.
The flowchart below shows the extra processing an IP packet received on
a Cable interface must go through before being allowed to proceed through the
The flowchart starts with a packet being received by an upstream port
on the CMTS and ends with the packet either being allowed to continue on for
further processing or in the packet being dropped.
The first Denial of Service scenario we will address is the situation
involving duplicate IP addresses. Let's say that customer A is connected to his
service provider and has obtained a valid DHCP lease for his PC. The IP address
Customer A has obtained will be known as X.
Sometime after A acquires his DHCP lease, customer B decides to
configure his PC with a static IP address that happens to be the same as that
currently being used by Customer A's equipment. The CPE Database information in
regards to IP address X would change depending on which CPE device last sent an
ARP request on behalf of X.
In an unprotected DOCSIS network, Customer B might be able to convince
the next hop router (in most cases, the CMTS) that he has the right to use IP
address X by simply sending an ARP request on behalf of X to the CMTS or
next-hop router. This would stop traffic from the service provider from being
forwarded to Customer A.
By enabling cable source-verify, the CMTS would be able to see that IP
and ARP packets for IP address X were being sourced from the wrong cable modem
and hence, these packets would be dropped, see Flowchart 2. This includes all
IP packets with source address X and ARP requests on behalf of X. The CMTS logs
would show a message along the lines of:
%UBR7200-3-BADIPSOURCE: Interface Cable3/0, IP packet from invalid
source. IP=192.168.1.10, MAC=0001.422c.54d0, Expected SID=10, Actual SID=11
Using this information, both clients would be identified and the Cable
Modem with the connected duplicate IP address can be disabled.
Another scenario is for a user to statically assign an unused as yet IP
address to their PC that falls within the legitimate range of CPE addresses.
This scenario does not cause any disruption of services to anyone in the
network. Let's say that customer B has assigned address Y for their PC.
The next problem that may arise is that Customer C might connect his
workstation to the service provider's network and acquire a DHCP lease for IP
address Y. The CPE Database would temporarily mark IP address Y as belonging
behind Customer C's Cable Modem. However, it might not be long before Customer
B, the non-legitimate user sends the appropriate sequence of ARP traffic to
convince the next-hop that he was the legitimate owner of IP address Y, hence
causing an interruption to Customer C's service.
Similarly, the second problem can be solved by turning on
cable source-verify. When cable
source-verify is turned on, a CPE Database entry that has been
generated by gleaning details from a DHCP transaction cannot be displaced by
other kinds of IP traffic. Only another DHCP transaction for that IP address or
the ARP entry on the CMTS timing out for that IP address can displace the
entry. This ensures that if an end user successfully acquires a DHCP lease for
a given IP address, that customer will not have to worry about the CMTS
becoming confused and thinking that his IP address belongs to another user.
The first problem of stopping users from using as yet unused IP
addresses can be solved with cable source-verify
dhcp. By adding the dhcp parameter to the end of this command,
the CMTS can check the validity of every new source IP address it hears about
by issuing a special type of DHCP message called a LEASEQUERY to the DHCP
server. See Flowchart 3.
For a given CPE IP address, the LEASEQUERY message asks what the
corresponding MAC address and Cable Modem are. See
Message for more details.
In this situation, if Customer B connects his workstation to the cable
network with static address Y, the CMTS will send a LEASEQUERY to the DHCP
server to verify if address Y has been leased to Customer B's PC. The DHCP
server is able to inform the CMTS that no lease has been granted for IP address
Y and hence customer B will be denied access.
Users may have workstations configured behind their cable modems with
static IP addresses which may not conflict with any of the service provider's
current network numbers, but which may cause problems in the future. Therefore,
using cable source-verify, a CMTS is able to filter out packets coming from
source IP addresses that are not from the range configured on the CMTS's cable
Note: In order for this to work properly, you also need to configure the
ip verify unicast reverse-path command so as to
prevent spoofed IP source addresses. Refer to
Commands: cable s for more information.
Some customers may have a router as a CPE device and arrange for the
service provider to route traffic to this router. If the CMTS receives IP
traffic from the CPE router with a source IP address of Z, then cable
source-verify will let this packet through if the CMTS has a route to the
network Z belongs to via that CPE device. Refer to Flowchart 3.
Now consider the following example:
On the CMTS we have the following config:
interface cable 3/0
ip verify unicast reverse-path
ip address 10.1.1.1 255.255.255.0
ip address 220.127.116.11 255.255.255.0 secondary
ip route 18.104.22.168 255.255.255.0 22.214.171.124
Note: This configuration shows only what is
relevant for this example
Assuming that a packet with source IP address 172.16.1.10 arrived at
the CMTS from cable modem 126.96.36.199, the CMTS would see that 188.8.131.52 does not
reside in the CPE database, show int cable x/y modem
0, however ip verify unicast
reverse-path enables Unicast Reverse Path Forwarding (Unicast
RPF), which checks each packet received on an interface in order to verify that
the source IP address of the packet appears in the routing tables that belongs
to that interface. The cable source-verify checks to
see what the next hop for 184.108.40.206 is. In the configuration above we have
ip route 220.127.116.11 255.255.255.0 18.104.22.168 which means that the
next hop is 22.214.171.124. Now assuming 126.96.36.199 is a valid entry in the CPE
database then the CMTS concludes that the packet is OK and hence will process
the packet as per Flowchart 4.
Configuring cable source-verify simply
involves adding the cable source-verify command to
the cable interface that you'd like to activate the function on. If you're
using cable interface bundling, then you need to add cable
source-verify to the master interface's configuration.
How to configure cable source-verify
cable source-verify was first introduced
in Cisco IOS Software Release 12.0(7)T and is supported in Cisco IOS Software
Releases 12.0SC, 12.1EC and 12.1T.
Configuring cable source-verify dhcp
requires a few steps.
Make sure that your DHCP server supports the special DHCP
In order to make use of the cable source-verify
dhcp functionality, your DHCP server must answer to the messages
as specified by draft-ietf-dhcp-leasequery-XX.txt. Cisco Network Registrar
versions 3.5 and above are able to answer to this message.
Make sure that your DHCP server supports Relay Agent
Information Option processing. Please see these instructions.
Another feature that must be supported by your DHCP server is DHCP
Relay Information Option processing. This is otherwise known as Option 82
processing. This Option is described in DHCP Relay Information Option (RFC
3046). Cisco Network Registrar versions 3.5 and above support Relay Agent
Information Option processing however it must be activated via the Cisco
Network Registrar command line utility nrcmd with the following sequence of
nrcmd -U admin -P changeme -C 127.0.0.1 dhcp enable
nrcmd -U admin -P changeme -C 127.0.0.1 save
nrcmd -U admin -P changeme -C 127.0.0.1 dhcp reload
You may need to substitute the appropriate username, password and
server IP address, the above shows default values. Alternatively, if you're at
the nrcmd prompt, >nrcmd you just type the following:
dhcp enable save-relay-agent-data
Turn on DHCP relay information option processing on the CMTS.
The CMTS must tag DHCP requests from Cable Modems and CPE with the
Relay Agent Information Option in order for cable source-verify
dhcp to be effective. The following commands must be entered in
global configuration mode on a CMTS running Cisco IOS Software Releases 12.1EC,
12.1T or later versions of Cisco IOS.
ip dhcp relay information option
If your CMTS is running Cisco IOS Software Releases 12.0SC train Cisco
IOS then use the cable relay-agent-option cable
interface command instead.
Be careful to use the appropriate commands, depending on the version of
Cisco IOS that you are running. Make sure to update your configuration if you
change trains of Cisco IOS.
The relay information option commands add a
special option called Option 82, or the relay information option, to the
relayed DHCP packet when the CMTS relays DHCP packets.
Option 82 is populated with a sub-option, the Agent Circuit-ID, that
references the physical interface on the CMTS that the DHCP request was heard
on. In addition to this, another sub-option, the Agent Remote ID, is populated
with the 6 byte MAC address of the cable modem that the DHCP request was
received from or passed through.
So, for example, if a PC with MAC address 99:88:77:66:55:44 which is
behind cable modem aa:bb:cc:dd:ee:ff sends a DHCP request, the CMTS will
forward the DHCP request setting the Agent Remote ID sub-option of Option 82 to
the MAC address of the Cable Modem, aa:bb:cc:dd:ee:ff.
By having the Relay Information Option included within the DHCP request
from a CPE device, the DHCP server is able to store information about which CPE
belongs behind what Cable Modems. This becomes especially useful when
cable source-verify dhcp is configured on the CMTS,
as the DHCP server is able to reliably inform the CMTS about not only what MAC
address a particular client should have, but which cable modem particular
client is meant to be connected to.
Enable the cable source-verify dhcp command under the
appropriate cable interface.
The final step is to enter the cable source-verify
dhcp command under the cable interface on which you'd like the
feature activated. If the CMTS is using cable interface bundling then you must
enter the command under the bundle's master interface.
The cable source-verify suites of commands
allow a service provider to protect the cable network from users with
unauthorized IP addresses to use the network.
The cable source-verify command by itself is an effective and easy way
to implement IP address security. While it does not cover all scenarios, it at
lease makes sure that customers with the right to use assigned IP addresses,
will not encounter any disruptions by having their IP address being used by
In its simplest form as described in this document, a CPE device not
configured via DHCP cannot obtain network access. This is the best way to
secure IP address space and increase the stability and reliability of a Data
over Cable service. However multiple service operators (MSOs) that have
comercial services which required them to use static addresses wanted to
implement strict security of the commandcable source-verify
Cisco Network Registrar version 5.5 has a new capability of responding
to the lease query for "reserved" addresses, even though the IP address was not
obtained via DHCP. The DHCP server includes lease reservation data in the
DHCPLEASEQUERY responses. In the previous releases of Network Registrar, the
DHCPLEASEQUERY responses were possible only for leased or previously leased
clients for which the MAC address was stored. Cisco uBR relay agents, for
example, discard DHCPLEASEQUERY datagrams not having a MAC address and lease
time (dhcp-lease-time option).
Network Registrar returns a default lease time of one year (31536000
seconds) for reserved leases in a DHCPLEASEQUERY response. If the address is
actually leased, Network Registrar returns its remaining lease time. More
features can be found at the Querying Leases section of
DHCP Scopes and Leases.