Test Case Descriptions
- Modules: 61
- Test Cases: 740
Below is a full description of the testcases in each module
basic.tcl
Initial connectivity tests to verify ARP and DHCP client are connected
| Test |
Module |
Name |
Synopsis |
Router responds to ARP request on LAN interface |
basic.tcl |
cdrouter_basic_1 |
Router responds to ARP request on LAN interface |
step 1. Send an ARP request to LAN client's default gateway
step 2. Verify that a valid ARP response is received
| Test |
Module |
Name |
Synopsis |
Router responds to ARP request on WAN interface |
basic.tcl |
cdrouter_basic_2 |
Router responds to ARP request on WAN interface |
step 1. Send an ARP request for router's WAN IP address
step 2. Verify that a valid ARP reply is received
step 3. Verify that the MAC address in the ARP reply matches expected MAC
address of the DUT's WAN interface
NOTE: This test is only run if the WAN interface mode supports ARP. This
test is skipped for wanMode PPPoE.
NOTE: To configure the expected MAC address of the DUT's WAN interface,
configure the testvar "wanDutMac". If this testvar is not defined, Step 3
will be skipped.
| Test |
Module |
Name |
Synopsis |
Verify LAN DHCP clients receive gateway/DNS configuration from WAN side |
basic.tcl |
cdrouter_basic_10 |
Verify LAN DHCP clients receive gateway/DNS configuration from WAN side |
step 1. Start new DHCP client on LAN interface
step 2. Verify the received DHCP options match the WAN configuration
step 3. Verify network mask matches configured network mask
step 4. Verify gateway is router's LAN IP address
step 5. Verify DNS server is one of the following values:
a. WAN ISP DNS server, if the testvar DNStoDHCP is set to 'yes'
b. A user defined DNS server if the testvar lanDnsServer is enabled
and the testvar DNStoDHCP is set to 'no'
c. The DUT's LAN IP if the testvar lanDnsServer is disabled and the
testvar DNStoDHCP is set to 'no'
step 6. If the WAN is running DHCP, verify domain is WAN ISP domain name
| Test |
Module |
Name |
Synopsis |
Outbound packets use specified/cloned source MAC address |
basic.tcl |
cdrouter_basic_20 |
Outbound packets use specified/cloned source MAC address |
step 1. Send an ICMP Echo Request from the LAN to the remote host IPv4
step 2. Verify that an ICMP Echo Request is received on the WAN
step 3. Verify that the source MAC address in the ICMP Echo Request received
on the WAN matches the expected MAC address of DUT's WAN interface
NOTE: To configure the expected MAC address of the DUT's WAN interface,
configure the testvar "wanDutMac". If this testvar is not defined, this test
case will be skipped.
dhcp-c.tcl
DHCP client tests for the WAN side of the router
| Test |
Module |
Name |
Synopsis |
DHCP client renews lease when current lease expires |
dhcp-c.tcl |
cdrouter_dhcp_1 |
DHCP client renews lease when current lease expires |
step 1. Wait for DHCP lease to expire
step 2. Verify WAN client sends DHCPREQUEST for same IP address
step 3. Reassign the same IP address
| Test |
Module |
Name |
Synopsis |
DHCP client resends DHCPREQUEST packet if server does not respond |
dhcp-c.tcl |
cdrouter_dhcp_2 |
DHCP client resends DHCPREQUEST packet if server does not respond |
step 1. Wait for DHCP lease to expire
step 2. Verify WAN client sends DHCPREQUEST for same IP address
step 3. Do not respond to request
step 4. Verify WAN client resends DHCPREQUEST for same IP address
step 5. Respond to request
| Test |
Module |
Name |
Synopsis |
DHCP client drops back into DISCOVERY mode if original server stops responding |
dhcp-c.tcl |
cdrouter_dhcp_3 |
DHCP client drops back into DISCOVERY mode if original server stops responding |
step 1. Disable DHCP server
step 2. Wait for DHCP lease to expire for WAN DHCP client
step 3. Verify WAN client sends DHCPREQUEST for same IP address
step 4. Do not respond to request
step 5. Verify WAN client resends DHCPREQUEST for same IP address
step 6. Verify WAN client eventually sends DHCPDISCOVER
| Test |
Module |
Name |
Synopsis |
DHCP client drops back into DISCOVERY mode if server sends a DHCPNAK |
dhcp-c.tcl |
cdrouter_dhcp_4 |
DHCP client drops back into DISCOVERY mode if server sends a DHCPNAK |
step 1. Configure DHCP server to respond to all DHCP requests with
DHCPNAK
step 2. Wait for DHCP lease to expire for WAN DHCP client
step 3. Verify WAN client sends DHCPREQUEST for same IP address
step 4. Send DHCPNAK to WAN client
step 5. Verify WAN client restarts DHCP and eventually sends DHCPDISCOVER
before any other DHCP message
step 6. Restore DHCP server's original behavior
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 3.2: Client-server interaction - reusing a previously allocated network address
If the client receives a DHCPNAK message, it cannot reuse its
remembered network address. It must instead request a new
address by restarting the configuration process, this time
using the (non-abbreviated) procedure described in section
3.1. This action also corresponds to the client moving to
the INIT state in the DHCP state diagram.
https://tools.ietf.org/html/rfc2131#section-3.2
| Test |
Module |
Name |
Synopsis |
DHCP client remains in DISCOVERY mode if server sends a DHCPNAK |
dhcp-c.tcl |
cdrouter_dhcp_5 |
DHCP client remains in DISCOVERY mode if server sends a DHCPNAK |
step 1. Configure DHCP server to respond to all DHCP requests with
DHCPNAK
step 2. Wait for DHCP lease to expire for WAN DHCP client
step 3. Send DHCPNAK to WAN client
step 4. Verify WAN client restarts DHCP and eventually sends DHCPDISCOVER
step 5. Send DHCPOFFER to WAN client
step 6. Verify WAN client sends a broadcast DHCPREQUEST
step 7. Send DHCPNAK to WAN client
step 8. Verify WAN client restarts DHCP and eventually sends DHCPDISCOVER
before any other DHCP message
step 9. Restore DHCP server's original behavior
step 10. Verify WAN client is assigned an IP address
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 3.1: Client-server interaction - allocating a network address
If the client receives a DHCPNAK message, the client restarts the
configuration process.
https://tools.ietf.org/html/rfc2131#section-3.1
| Test |
Module |
Name |
Synopsis |
DHCP client ignores site-specific DHCP options |
dhcp-c.tcl |
cdrouter_dhcp_10 |
DHCP client ignores site-specific DHCP options |
step 1. Disable DHCP server to force client back to DISCOVERY mode
step 2. Wait for DHCP lease to expire for WAN DHCP client
step 3. Verify WAN client sends DHCPREQUEST for same IP address
step 4. Do not respond to request
step 5. Verify WAN client resends DHCPREQUEST for same IP address
step 6. Verify WAN client eventually sends DHCPDISCOVER
step 7. Enable DHCP server with site specific options
step 8. Verify DHCP client is able to obtain new IP address
| Test |
Module |
Name |
Synopsis |
Verify DHCP client handles server option with length 0 |
dhcp-c.tcl |
cdrouter_dhcp_11 |
Verify DHCP client handles server option with length 0 |
step 1. Disable DHCP server to force client back to DISCOVERY mode
step 2. Wait for WAN DHCP client lease to expire
step 3. Verify WAN client sends DHCPREQUEST for same IP address
step 4. Do not respond to request
step 5. Verify WAN client resends DHCPREQUEST for same IP address
step 6. Verify WAN client eventually sends DHCPDISCOVER
step 7. Enable DHCP server
step 8. Add site specific option with length 0
step 9. Verify client is able to obtain new IP address
| Test |
Module |
Name |
Synopsis |
DHCP client ignores DHCP packets with corrupt UDP checksum |
dhcp-c.tcl |
cdrouter_dhcp_20 |
DHCP client ignores DHCP packets with corrupt UDP checksum |
step 1. Configure DHCP server to send DHCP packets with corrupt UDP checksum
step 2. Wait for WAN client DHCP lease to expire
step 3. Verify WAN client sends DHCPREQUEST
step 4. Verify server responds with invalid UDP checksum
step 5. Verify WAN client eventually sends DHCPDISCOVER
step 6. Verify WAN client sends a second DHCPDISCOVER
step 7. Configure DHCP server to send valid UDP checksums
step 8. Verify WAN client can now obtain an IP address
| Test |
Module |
Name |
Synopsis |
DHCP client includes vendor defined options |
dhcp-c.tcl |
cdrouter_dhcp_30 |
DHCP client includes vendor defined options |
step 1. Wait for DHCP lease to expire
step 2. Verify WAN client sends DHCPREQUEST for same IP address
step 3. Reassign the same IP address
step 4. Search DHCPREQUEST for expected options
The testvars wanDhcpClientOptionCode and wanDhcpClientOptionData can
be used to configure a list of DHCP options that the client should
include in requests sent to the DHCP server.
| Test |
Module |
Name |
Synopsis |
Verify client supports DHCP Rapid Commit option |
dhcp-c.tcl |
cdrouter_dhcp_31 |
Verify client supports DHCP Rapid Commit option |
step 1. Disable DHCP server
step 2. Wait for DHCP lease to expire for WAN DHCP client
step 3. Verify WAN client sends DHCPREQUEST
step 4. Do not respond to request
step 5. Verify WAN client eventually sends DHCPDISCOVER
step 6. Verify DHCPDISCOVER contains Rapid Commit option
References:
IETF RFC 4039 "Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4)" Section 3.1: Client/Server Operation
https://tools.ietf.org/html/rfc4039#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify client supports DHCP Forcerenew Nonce Authentication |
dhcp-c.tcl |
cdrouter_dhcp_32 |
Verify client supports DHCP Forcerenew Nonce Authentication |
step 1. Verify DHCP Forcerenew Authentication nonce for WAN client
exists
step 2. Send DHCPFORCERENEW using client nonce
step 3. Verify WAN client sends DHCPREQUEST packet
References:
IETF RFC 3203 "DHCP reconfigure extension" Section 2.2: Force renew procedures
https://tools.ietf.org/html/rfc3203#section-2.2
IETF RFC 6704 "Forcerenew Nonce Authentication" Section 3.1.4: Client Considerations for Forcerenew Nonce Authentication
https://tools.ietf.org/html/rfc6704#section-3.1.4
| Test |
Module |
Name |
Synopsis |
Verify client ignores DHCPFORCERENEW without Authentication option |
dhcp-c.tcl |
cdrouter_dhcp_33 |
Verify client ignores DHCPFORCERENEW without Authentication option |
step 1. Verify DHCP Forcerenew Authentication nonce for WAN client
exists
step 2. Send DHCPFORCERENEW using client nonce without
Authentication option
step 3. Verify WAN client does not send DHCPREQUEST packet
References:
IETF RFC 3203 "DHCP reconfigure extension" Section 6: Security Considerations
https://tools.ietf.org/html/rfc3203#section-6
| Test |
Module |
Name |
Synopsis |
Verify client ignores DHCPFORCERENEW authenticated with incorrect nonce |
dhcp-c.tcl |
cdrouter_dhcp_34 |
Verify client ignores DHCPFORCERENEW authenticated with incorrect nonce |
step 1. Verify DHCP Forcerenew Authentication nonce for WAN client
exists
step 2. Send DHCPFORCERENEW using incorrect client nonce
step 3. Verify WAN client does not send DHCPREQUEST packet
Reference:
IETF RFC 6704 Section 3.1.4 "Client Considerations for Forcerenew Nonce Authentication"
IETF RFC 6704 Section 5 "Security Considerations"
References:
IETF RFC 6704 "Forcerenew Nonce Authentication" Section 3.1.4: Client Considerations for Forcerenew Nonce Authentication
https://tools.ietf.org/html/rfc6704#section-3.1.4
IETF RFC 6704 "Forcerenew Nonce Authentication" Section 5: Security Considerations
https://tools.ietf.org/html/rfc6704#section-5
| Test |
Module |
Name |
Synopsis |
Verify client ignores DHCPFORCERENEW messages on port 67 |
dhcp-c.tcl |
cdrouter_dhcp_35 |
Verify client ignores DHCPFORCERENEW messages on port 67 |
step 1. Verify DHCP Forcerenew Authentication nonce for WAN client
exists
step 2. Send DHCPFORCERENEW to the client on port 67
step 3. Verify WAN client does not send DHCPREQUEST packet
References:
IETF RFC 6704 "Forcerenew Nonce Authentication" Section 3.1.4: Client Considerations for Forcerenew Nonce Authentication
https://tools.ietf.org/html/rfc6704#section-3.1.4
IETF RFC 6704 "Forcerenew Nonce Authentication" Section 5: Security Considerations
https://tools.ietf.org/html/rfc6704#section-5
| Test |
Module |
Name |
Synopsis |
Verify client ignores DHCPOFFER messages on port 67 |
dhcp-c.tcl |
cdrouter_dhcp_36 |
Verify client ignores DHCPOFFER messages on port 67 |
step 1. Wait for the DHCP lease to expire on the DUT
step 2. Configure the DHCP server to send a DHCPNACK
step 3. Wait for the DUT to send a DHCPDISCOVER
step 4. Send a DHCPOFFER to port 67
step 5. Verify the DUT doesn't respond with a DHCPREQUEST
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4: Constructing and sending DHCP messages
https://tools.ietf.org/html/rfc2131#section-4
| Test |
Module |
Name |
Synopsis |
Verify client requests same parameters in all subsequent DHCP messages |
dhcp-c.tcl |
cdrouter_dhcp_40 |
Verify client requests same parameters in all subsequent DHCP messages |
step 1. Disable DHCP server
step 2. Wait for DHCP lease to expire for WAN DHCP client
step 3. Verify WAN client eventually sends DHCPDISCOVER
step 4. Record the DHCP Parameter Request List option in DHCPDISCOVER
step 5. Enable DHCP server
step 6. Verify WAN client sends DHCPREQUEST
step 7. Record the DHCP Parameter Request List in DHCPREQUEST
step 8. Verify WAN client sends DHCPREQUEST to renew lease
step 9. Record the DHCP Parameter Request List in DHCPREQUEST sent during
renewal
step 10. Verify DHCP Parameter Request List option contents are consistent
across DHCP messages (verify that the steps 4, 7, and 9)
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.2: DHCPREQUEST message
If the client included a list of requested parameters in a DHCPDISCOVER
message, it MUST include that list in all subsequent messages.
https://tools.ietf.org/html/rfc2131#section-4.3.2
| Test |
Module |
Name |
Synopsis |
Verify client uses same Client ID in all subsequent DHCP messages |
dhcp-c.tcl |
cdrouter_dhcp_41 |
Verify client uses same Client ID in all subsequent DHCP messages |
step 1. Disable DHCP server
step 2. Wait for DHCP lease to expire for WAN DHCP client
step 3. Verify WAN client eventually sends DHCPDISCOVER
step 4. Record the DHCP ClientID
step 5. Enable DHCP server
step 6. Verify WAN client sends DHCPREQUEST
step 7. Record the DHCP ClientID
step 8. Verify WAN client sends DHCPREQUEST for renewal
step 9. Record the DHCP ClientID
step 10. Verify DHCP ClientID is consistent across DHCP messages
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 2: Protocol Summary
If the client uses a 'client identifier' in one message, it MUST use that
same identifier in all subsequent messages, to ensure that all servers
correctly identify the client.
If the client does not use the DHCP Client ID option 61, the client ID will
be the src MAC address.
https://tools.ietf.org/html/rfc2131#section-2
| Test |
Module |
Name |
Synopsis |
Verify client uses a randomized exponential backoff algorithm for DHCPDISCOVER retransmissions |
dhcp-c.tcl |
cdrouter_dhcp_50 |
Verify client uses a randomized exponential backoff algorithm for DHCPDISCOVER retransmissions |
step 1. Disable DHCP server
step 2. Wait for DHCP lease to expire for WAN DHCP client
step 3. Verify WAN client sends DHCPREQUEST
step 4. Do not respond to request
step 5. Verify WAN client eventually sends DHCPDISCOVER
step 6. Do not respond to discover
step 7. Verify WAN client continues to retransmit DHCPDISCOVER
using a randomized exponential backoff algorithm
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.1: Constructing and sending DHCP messages
DHCP clients are responsible for all message retransmission. The
client MUST adopt a retransmission strategy that incorporates a
randomized exponential backoff algorithm to determine the delay
between retransmissions. The delay between retransmissions SHOULD be
chosen to allow sufficient time for replies from the server to be
delivered based on the characteristics of the internetwork between
the client and the server. For example, in a 10Mb/sec Ethernet
internetwork, the delay before the first retransmission SHOULD be 4
seconds randomized by the value of a uniform random number chosen
from the range -1 to +1. Clients with clocks that provide resolution
granularity of less than one second may choose a non-integer
randomization value. The delay before the next retransmission SHOULD
be 8 seconds randomized by the value of a uniform number chosen from
the range -1 to +1. The retransmission delay SHOULD be doubled with
subsequent retransmissions up to a maximum of 64 seconds. The client
MAY provide an indication of retransmission attempts to the user as
an indication of the progress of the configuration process.
https://tools.ietf.org/html/rfc2131#section-4.1
| Test |
Module |
Name |
Synopsis |
DHCP client obtains lease when server delays responses |
dhcp-c.tcl |
cdrouter_dhcp_60 |
DHCP client obtains lease when server delays responses |
step 1. Disable DHCP server
step 2. Wait for DHCP lease to expire for WAN DHCP client
step 3. Verify WAN client sends DHCPREQUEST for same IP address
step 4. Do not respond to request
step 5. Verify WAN client eventually sends DHCPDISCOVER
step 6. Do not respond to request
step 7. Configure DHCP server to delay all responses
step 8. Verify WAN client sends a second DHCPDISCOVER
step 9. Verify WAN client can now obtain an IP address
NOTE: The testvar dhcpServerResponseDelay can be used to
specify the delay used by CDRouter's DHCP server on the WAN
for this testcase.
| Test |
Module |
Name |
Synopsis |
DHCP client is able to rebind to alternate DHCP server |
dhcp-c.tcl |
cdrouter_dhcp_70 |
DHCP client is able to rebind to alternate DHCP server |
step 1. Disable the DHCP server
step 2. Wait for the DUT to send a DHCPREQUEST to renew its lease
step 3. Ignore the DUT's requests and allow it to enter the REBINDING state
step 4. Verify that the DUT is in the REBIND state by checking that it
is broadcasting DHCPREQUESTs
step 5. Reconfigure the DHCP server to a new IP address and enable it
step 6. Allow the DHCP server to respond with an DHCPACK to the client
step 7. Send an ARP request to the client
step 8. Verify it was able to renew its original address by responding
to the ARP request
step 9. If a LAN client is configured ping a remote host from a LAN client
step 10. Verify that traffic is correctly transmitted and the DUT is using
the new gateway
step 11. Wait for another address renew from the DUT
step 12. Verify the DUT has learned the new DHCP server address
step 13. Verify that at no point did the DUT fall back into the INIT
state and broadcast DISCOVERY messages
NOTE: steps 9 and 10 are optional and only performed if there
is a LAN client configured.
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.2: DHCPREQUEST message
DHCPREQUEST generated during REBINDING state:
In this situation, the client is completely
configured, and is trying to extend its lease. This message MUST
be broadcast to the 0xffffffff IP broadcast address. The DHCP
server SHOULD check 'ciaddr' for correctness before replying to
the DHCPREQUEST.
The DHCPREQUEST from a REBINDING client is intended to accommodate
sites that have multiple DHCP servers and a mechanism for
maintaining consistency among leases managed by multiple servers.
A DHCP server MAY extend a client's lease only if it has local
administrative authority to do so.
https://tools.ietf.org/html/rfc2131#section-4.3.2
pppoe-c.tcl
PPPoE client tests for the WAN side of the router
| Test |
Module |
Name |
Synopsis |
PPPoE client restarts PPPoE Discovery when PPP LCP Echo-Requests fail |
pppoe-c.tcl |
cdrouter_pppoe_client_1 |
PPPoE client restarts PPPoE Discovery when PPP LCP Echo-Requests fail |
step 1. Turn off PPP LCP Echo-Reply on PPPoE server
step 2. PPP client should send an LCP Echo-Request
step 3. PPP client will not receive an LCP Echo-Reply
step 4. Verify WAN PPPoE client sends PADI to restart PPPoE Discovery
(wait upto 5 minutes for LCP to failover)
step 5. Verify PPPoE client brings new PPPoE session up
NOTE: Most PPPoE clients will terminate the existing PPPoE session after
several LCP Echo-Requests have failed. However, some routers will
simply initiate a new PPPoE session without sending a PADT. This
test case does not FAIL the test if the existing PPPoE session is not
terminated before starting a new PPPoE session. However, a warning
will be issued.
NOTE: The amount of time the test waits to recover the PPP based
link can be configured by adjusting the testvar pppRestartTimeout.
This variable contains the number of milliseconds to wait for
PPP based protocols to recover. The default is 300000 (300 seconds).
NOTE: By default, CDRouter will still respond to ICMP Echo
Requests during this test. This allows the test to verify failure
occurs because of PPP and not the ICMP Echo Replies. However, you
can configure CDRouter to also ignore ICMP Echo Requests during
this test by setting the testvar pppFailUsesICMP to yes.
| Test |
Module |
Name |
Synopsis |
PPPoE client restarts PPPoE Discovery when PPP LCP terminates PPP link |
pppoe-c.tcl |
cdrouter_pppoe_client_10 |
PPPoE client restarts PPPoE Discovery when PPP LCP terminates PPP link |
step 1. Check the current PPPoE session is established
step 2. Terminate the current PPP session using LCP Terminate
step 3. Verify WAN PPPoE client sends PADI to restart PPPoE Discovery
step 4. Verify PPPoE client brings new PPPoE session up
NOTE: The amount of time the test waits to recover the PPP based
link can be configured by adjusting the testvar pppRestartTimeout.
This variable contains the number of milliseconds to wait for
PPP based protocols to recover. The default is 300000 (300 seconds).
| Test |
Module |
Name |
Synopsis |
PPPoE PPP client replies to LCP Echo-Requests |
pppoe-c.tcl |
cdrouter_pppoe_client_50 |
PPPoE PPP client replies to LCP Echo-Requests |
step 1. Send 5 LCP Echo-Requests
step 2. Verify LCP Echo-Replies are received
step 3. Verify LCP Echo-Request data is echoed back in response
| Test |
Module |
Name |
Synopsis |
PPPoE PPP client maintains LCP Magic Number during session |
pppoe-c.tcl |
cdrouter_pppoe_client_60 |
PPPoE PPP client maintains LCP Magic Number during session |
step 1. Terminate the current PPP session using LCP Terminate
step 2. Check for Magic Number in LCP Configure Request
step 3. Wait for LCP Echo Request and verify Magic Number is the same
step 4. Send LCP Echo Request
step 5. Verify Magic Number in LCP Echo Response is the same
NOTE: CDRouter does not fail this test if the PPPoE PPP client
does not send an LCP Echo Request. Some clients do not
use LCP Echo Requests automtically.
References:
IETF RFC 1548 "The Point-to-Point Protocol (PPP)" Section 5.8: Echo-Request and Echo-Reply
https://tools.ietf.org/html/rfc1548#section-5.8
| Test |
Module |
Name |
Synopsis |
PPPoE/PPP restarts if PPP authentication fails |
pppoe-c.tcl |
cdrouter_pppoe_client_200 |
PPPoE/PPP restarts if PPP authentication fails |
step 1. Terminate the current PPP session using LCP Terminate
step 2. Verify WAN PPPoE client sends PADI to restart PPPoE Discovery
step 3. Verify PPPoE client brings new PPPoE session up
step 4. Reject any PAP or CHAP authentication attempts
step 5. Wait 60 seconds, continuing to reject PPP authentication
step 6. Accept PPP authentication after 60 seconds
step 7. Send pings from LAN side to WAN side to force link to reestablish
step 8. Verify PPP link is reestablished in 300 seconds (pppRestartTimeout)
NOTE: This test supports PAP, CHAP, and MSCHAP authentication.
NOTE: The amount of time the test waits to recover the PPP based
link can be configured by adjusting the testvar pppRestartTimeout.
This variable contains the number of milliseconds to wait for
PPP based protocols to recover. The default is 300000 (300 seconds).
| Test |
Module |
Name |
Synopsis |
PPPoE/PPP can recover if LCP renegotiation is attempted |
pppoe-c.tcl |
cdrouter_pppoe_client_210 |
PPPoE/PPP can recover if LCP renegotiation is attempted |
step 1. Send LCP Configure-Request to PPP peer
step 2. Verify peer resends LCP configuration
step 3. Verify the configuration is the same
step 4. If the PPPoE link is terminated, issue ping to reestablish link
step 5. Verify ping succeeds from LAN to WAN
NOTE: Renegotiating LCP can cause some PPP implementations to terminate
the PPP link or the PPPoE link. This test does not fail the DUT if this
happens, but it does issue a warning if the PPPoE session is restarted.
NOTE: The amount of time the test waits to recover the PPP based
link can be configured by adjusting the testvar pppRestartTimeout.
This variable contains the number of milliseconds to wait for
PPP based protocols to recover. The default is 300000 (300 seconds).
| Test |
Module |
Name |
Synopsis |
PPPoE/PPP can recover if LCP Echo-Request contains bad length |
pppoe-c.tcl |
cdrouter_pppoe_client_230 |
PPPoE/PPP can recover if LCP Echo-Request contains bad length |
step 1. Send out LCP Echo-Request with length 4096, but no data
step 2. Peer may respond or drop LCP Echo-Request
step 3. Verify PPP is still functioning using ICMP Echo
NOTE: This test checks that the device under test behaves gracefully
when it receives PPP options with a bad length. Some devices may
still respond to the LCP Echo-Request, but it is not considered a failure if
the device does not respond.
| Test |
Module |
Name |
Synopsis |
PPPoE client recovers if PPPoE server drops PADR from PPPoE client |
pppoe-c.tcl |
cdrouter_pppoe_client_300 |
PPPoE client recovers if PPPoE server drops PADR from PPPoE client |
step 1. Terminate the current PPP session using LCP Terminate
step 2. Verify WAN PPPoE client sends PADI to restart PPPoE Discovery
step 3. Do not respond to the PADR packet from client
step 4. Continue to ignore any PPPoE packets from the client until
the client sends a new PADI packet
step 5. Restore PPPoE server to normal operation
step 6. Verify PPPoE client session recovers
NOTE: The amount of time the test waits to recover the PPP based
link can be configured by adjusting the testvar pppRestartTimeout.
This variable contains the number of milliseconds to wait for
PPP based protocols to recover. The default is 300000 (300 seconds).
References:
IETF RFC 2516 "A Method for Transmitting PPP Over Ethernet (PPPoE)" Section 8: Other Considerations
If the Host is waiting to receive a PADS packet, a similar timeout
mechanism SHOULD be used, with the Host re-sending the PADR. After
a specified number of retries, the Host SHOULD then resend a PADI
packet.
https://tools.ietf.org/html/rfc2516#section-8
| Test |
Module |
Name |
Synopsis |
PPPoE client returns AC-Cookie in PADR when server sends AC-Cookie in PADO |
pppoe-c.tcl |
cdrouter_pppoe_client_310 |
PPPoE client returns AC-Cookie in PADR when server sends AC-Cookie in PADO |
step 1. Configure PPPoE server to use AC-Cookie Tag in PADO responses
step 2. Terminate the current PPP session using LCP Terminate
step 3. Verify WAN PPPoE client sends PADI to restart PPPoE Discovery
step 4. Send AC-Cookie Tag in PADO
step 5. Verify PADR from client contains AC-Cookie with the same cookie data
References:
IETF RFC 2516 "A Method for Transmitting PPP Over Ethernet (PPPoE)" Section A: AC-Cookie
If a Host receives this TAG, it MUST return the TAG
unmodified in the following PADR.
https://tools.ietf.org/html/rfc2516
| Test |
Module |
Name |
Synopsis |
PPPoE client maintains Relay-Session-Id during PPPoE session establishment |
pppoe-c.tcl |
cdrouter_pppoe_client_320 |
PPPoE client maintains Relay-Session-Id during PPPoE session establishment |
step 1. Configure PPPoE server to use Relay-Session-Id in PADO responses
step 2. Terminate the current PPP session using LCP Terminate
step 3. Verify WAN PPPoE client sends PADI to restart PPPoE Discovery
step 4. If the PADI already contains a Relay-Session-Id from an actual
PPPoE Relay server, configure the PPPoE server to use the same
tag value
step 5. Send Relay-Session-Id Tag in PADO
step 6. Verify PADR from client contains Relay-Session-Id tag with the same cookie data
NOTE: Normally, CDRouter does not expect a PPPoE relay server to be present
between the PPPoE client and CDRouter. However, this test does check for
an existing Relay-Session-Id in the PADI and will use this tag value
for the test instead of generating a unique value. This allows the test
to work with an existing PPPoE relay server on the WAN.
References:
IETF RFC 2516 "A Method for Transmitting PPP Over Ethernet (PPPoE)" Section A: Relay-Session-Id
If either the Host or Access Concentrator receives this TAG they
MUST include it unmodified in any discovery packet they send as a response.
https://tools.ietf.org/html/rfc2516
| Test |
Module |
Name |
Synopsis |
PPPoE client sends PADT packet after idle timeout elapses |
pppoe-c.tcl |
cdrouter_pppoe_client_330 |
PPPoE client sends PADT packet after idle timeout elapses |
step 1. Ping from LAN to WAN to refresh idle timeout
step 2. Disable LAN client to prevent LAN to WAN traffic
step 3. Verify PPPoE client sends PADT packet after a configured
period of inactivity
NOTE: The amount of time the test waits to for the PADT packet can
be configured by adjusting the testvar pppoeIdleTimeout. This
variable contains the number of seconds to wait for PPPoE
connections to timeout when idling. The default is 60 seconds.
NOTE: This test is skipped if the testvar pppoeConnectOnDemand is
set to no.
| Test |
Module |
Name |
Synopsis |
Verify PPPoE client sends correct PPP-Max-Payload tag in PADI packets |
pppoe-c.tcl |
cdrouter_pppoe_client_400 |
Verify PPPoE client sends correct PPP-Max-Payload tag in PADI packets |
step 1. Turn off PPP LCP Echo-Reply on PPPoE server
step 2. PPP client should send an LCP Echo-Request
step 3. PPP client will not receive an LCP Echo-Reply
step 4. Verify WAN PPPoE client sends PADI to restart PPPoE Discovery
(wait upto 5 minutes for LCP to failover)
step 5. Verify the PADI contains a PPP-Max-Payload tag whose value
matches that of the testvar pppoeMaxPayload.
step 6. Verify PPPoE client brings new PPPoE session up
References:
IETF RFC 4638 "Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE)"
https://tools.ietf.org/html/rfc4638
pptp-c.tcl
PPTP client tests for the WAN side of the router
| Test |
Module |
Name |
Synopsis |
PPTP client restarts PPTP connection when PPTP Echo Requests fail |
pptp-c.tcl |
cdrouter_pptp_5 |
PPTP client restarts PPTP connection when PPTP Echo Requests fail |
step 1. Turn off PPTP Echo Replies on PPTP server
step 2. Verify WAN PPTP client closes PPTP TCP connection
(wait upto 5 minutes for PPTP to failover)
step 3. Continue to send data from LAN to WAN to initiate new connection
step 4. Verify PPTP client establishes new PPTP control session
step 5. Verify PPTP client establishes new PPTP outbound call session
step 6. Verify LAN side can reach WAN using new PPTP call id
NOTE: By default, CDRouter will still respond to ICMP Echo
Requests during this test. This allows the test to verify failure
occures because of PPP and not the ICMP Echo Replies. However, you
can configure CDRouter to also ignore ICMP Echo Requests during
this test by setting the testvar pppFailUsesICMP to yes:
References:
IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)" Section 3.1.4: Keep Alives and Timers
https://tools.ietf.org/html/rfc2637#section-3.1.4
| Test |
Module |
Name |
Synopsis |
PPTP client restarts PPTP connection when PPP LCP terminates PPP link |
pptp-c.tcl |
cdrouter_pptp_10 |
PPTP client restarts PPTP connection when PPP LCP terminates PPP link |
step 1. Terminate the current PPP session using LCP Terminate
step 2. Verify WAN PPTP client closes PPTP TCP session
step 3. Continue to send data from LAN to WAN to initiate new connection
step 4. Verify PPTP client establishes new PPTP control session
step 5. Verify PPTP client establishes new PPTP outbound call session
step 6. Verify LAN side can reach WAN using new PPTP call id
References:
IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)"
https://tools.ietf.org/html/rfc2637
| Test |
Module |
Name |
Synopsis |
PPTP client restarts PPTP connection when TCP control session is closed |
pptp-c.tcl |
cdrouter_pptp_20 |
PPTP client restarts PPTP connection when TCP control session is closed |
step 1. Initiate TCP close on PPTP control session by sending TCP FIN
step 2. Verify WAN PPTP client closes PPTP TCP connection
step 3. Continue to send data from LAN to WAN to initiate new connection
step 4. Verify PPTP client establishes new PPTP control session
step 5. Verify PPTP client establishes new PPTP outbound call session
step 6. Verify LAN side can reach WAN using new PPTP call id
NOTE: The behavior of the router when the PPTP TCP control session is
lost is not well defined by RFC 2637. On some implementations, this
causes the PPTP client to restart its control session. In the worst
case, the PPTP client should detect a dead connection through PPTP
Echo Request failires. At this point, the PPTP control session should
be restarted.
References:
IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)" Section 3.1.4: Keep Alives and Timers
https://tools.ietf.org/html/rfc2637#section-3.1.4
| Test |
Module |
Name |
Synopsis |
PPTP client restarts PPTP connection when TCP control session is reset |
pptp-c.tcl |
cdrouter_pptp_25 |
PPTP client restarts PPTP connection when TCP control session is reset |
step 1. Send TCP RST for PPTP control session
step 2. Continue to send data from LAN to WAN to initiate new connection
step 3. Verify PPTP client establishes new PPTP control session
step 4. Verify PPTP client establishes new PPTP outbound call session
step 5. Verify LAN side can reach WAN using new PPTP call id
NOTE: The behavior of the router when the PPTP TCP control session is
lost is not well defined by RFC 2637. On some implementations, this
causes the PPTP client to restart its control session. In the worst
case, the PPTP client should detect a dead connection through PPTP
Echo Request failires. At this point, the PPTP control session should
be restarted.
References:
IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)" Section 3.1.4: Keep Alives and Timers
https://tools.ietf.org/html/rfc2637#section-3.1.4
| Test |
Module |
Name |
Synopsis |
PPTP client initiates new call after a PPTP Call-Disconnect-Notify |
pptp-c.tcl |
cdrouter_pptp_30 |
PPTP client initiates new call after a PPTP Call-Disconnect-Notify |
step 1. Send PPTP Call-Disconnect-Notify for existing Call ID
step 2. Continue to send data from LAN to WAN to initiate new call
step 3. Verify PPTP client establishes new PPTP outbound call
step 4. Verify LAN side can reach WAN using new PPTP call id
NOTE: Some implementations may close the PPTP control session if
the PPTP call is disconnected. This test does not consider this a
failure as long as a valid PPTP outbound call is reestablished.
References:
IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)"
https://tools.ietf.org/html/rfc2637
| Test |
Module |
Name |
Synopsis |
PPTP PPP client replies to LCP Echo Requests |
pptp-c.tcl |
cdrouter_pptp_50 |
PPTP PPP client replies to LCP Echo Requests |
step 1. Send 5 LCP Echo Requests
step 2. Verify LCP Echo Replies are received
step 3. Verify LCP Echo Request data is echoed back in response
| Test |
Module |
Name |
Synopsis |
PPTP PPP client maintains LCP Magic Number during session |
pptp-c.tcl |
cdrouter_pptp_60 |
PPTP PPP client maintains LCP Magic Number during session |
step 1. Terminate the current PPP session using LCP Terminate
step 2. Check for Magic Number in LCP Configure Request
step 3. Wait for LCP Echo Request and verify Magic Number is the same
step 4. Send LCP Echo Request
step 5. Verify Magic Number in LCP Echo Response is the same
RFC 1548 The Point-to-Point Protocol
5.8 Echo-Request and Echo-Reply
NOTE: CDRouter does not fail this test if the PPTP PPP client
does not send an LCP Echo Request. Some clients do not
use LCP Echo Requests automtically.
| Test |
Module |
Name |
Synopsis |
PPTP/PPP restarts if PPP authentication fails |
pptp-c.tcl |
cdrouter_pptp_200 |
PPTP/PPP restarts if PPP authentication fails |
step 1. Terminate the current PPP session using LCP Terminate
step 2. Verify PPTP client closes current PPTP control session
step 3. Continue to send data from LAN to WAN
step 4. Reject any PAP or CHAP authentication attempts
step 5. Wait 60 seconds, continuing to reject PPP authentication
step 6. Accept PPP authentication after 60 seconds
step 7. Verify PPP link is reestablished in 120 seconds
Note: This test supports PAP and CHAP authentication.
| Test |
Module |
Name |
Synopsis |
PPTP/PPP can recover if LCP renegotiation is attempted |
pptp-c.tcl |
cdrouter_pptp_210 |
PPTP/PPP can recover if LCP renegotiation is attempted |
step 1. Send out LCP Configure-Request to PPP peer
step 2. Verify peer resends LCP configuration
step 3. Verify the configuration is the same
step 4. Verify ping succeeds from LAN to WAN
NOTE: Renegotiating LCP has can cause some PPP implementations to terminate
the PPP link or the PPTP link. This test does not fail the DUT if this
happens, but it does issue a warning if the PPTP session is restarted.
| Test |
Module |
Name |
Synopsis |
PPTP/PPP can recover if LCP Echo Request contains bad length |
pptp-c.tcl |
cdrouter_pptp_230 |
PPTP/PPP can recover if LCP Echo Request contains bad length |
step 1. Send LCP Echo Request with length 4096, but no data
step 2. Peer may respond or drop LCP Echo Request
step 3. Verify PPP is still functioning using ICMP echo
NOTE: This test checks that the device under test behaves gracefully
when it receives PPP options with a bad length. Some devices may
still respond to the LCP Echo Request, but its not considered a failure if
the device does not respond.
l2tp-c.tcl
L2TP client tests for WAN side of the router
| Test |
Module |
Name |
Synopsis |
L2TP client restarts L2TP connection when L2TP Hello Requests are unanswered |
l2tp-c.tcl |
cdrouter_l2tp_5 |
L2TP client restarts L2TP connection when L2TP Hello Requests are unanswered |
step 1. Turn off L2TP Hello Replies on L2TP server
step 2. Halt traffic on the L2TP tunnel
step 3. Verify the L2TP client sends L2TP Hello Requests to the server
step 4. Verify WAN L2TP client closes L2TP tunnel
step 5. Continue to send data from LAN to WAN to initiate new connection
step 6. Verify L2TP client establishes new L2TP session
step 7. Verify LAN side can reach WAN using new L2TP session
References:
IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""
https://tools.ietf.org/html/rfc2661
| Test |
Module |
Name |
Synopsis |
L2TP client restarts L2TP connection when PPP LCP terminates PPP link |
l2tp-c.tcl |
cdrouter_l2tp_10 |
L2TP client restarts L2TP connection when PPP LCP terminates PPP link |
step 1. Terminate the current PPP session using LCP Terminate
step 2. Verify WAN L2TP client closes L2TP TCP session
step 3. Continue to send data from LAN to WAN to initiate new connection
step 4. Verify L2TP client establishes new L2TP session
step 5. Verify LAN side can reach WAN using new L2TP call id
References:
IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""
https://tools.ietf.org/html/rfc2661
| Test |
Module |
Name |
Synopsis |
L2TP client initiates new L2TP connection after closing tunnel with StopCCN |
l2tp-c.tcl |
cdrouter_l2tp_20 |
L2TP client initiates new L2TP connection after closing tunnel with StopCCN |
step 1. Send the StopCCN command to close the active L2TP tunnel
step 2. Continue to send data from the LAN to WAN to initiate a new tunnel
step 3. Verify L2TP client establishes a new L2TP tunnel
step 4. Verify LAN side can reach WAN using new L2TP tunnel
References:
IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""
https://tools.ietf.org/html/rfc2661
| Test |
Module |
Name |
Synopsis |
L2TP client initiates new L2TP tunnel after receiving CDN and StopCCN |
l2tp-c.tcl |
cdrouter_l2tp_30 |
L2TP client initiates new L2TP tunnel after receiving CDN and StopCCN |
step 1. Send Call-Disconnect-Notify for the L2TP session
step 2. Send StopCCN for L2TP tunnel
step 3. Continue to send data from LAN to WAN to initiate new tunnel
step 4. Verify L2TP client establishes new L2TP tunnel
step 5. Verify LAN side can reach WAN using new L2TP tunnel
References:
IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""
https://tools.ietf.org/html/rfc2661
| Test |
Module |
Name |
Synopsis |
L2TP client sends HELLO after period of inactivity |
l2tp-c.tcl |
cdrouter_l2tp_40 |
L2TP client sends HELLO after period of inactivity |
step 1. Stop PPP from passing traffic to the WAN
step 2. Continue to send data from LAN to WAN
step 3. Verify L2TP sends HELLO message to L2TP server
step 4. Respond to HELLO
step 5. Reestablish PPP traffic from WAN
step 6. Verify LAN-WAN communication resumes
References:
IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""
https://tools.ietf.org/html/rfc2661
| Test |
Module |
Name |
Synopsis |
L2TP PPP client replies to LCP Echo Requests |
l2tp-c.tcl |
cdrouter_l2tp_50 |
L2TP PPP client replies to LCP Echo Requests |
step 1. Send 5 LCP Echo Requests
step 2. Verify LCP Echo Replies are received
step 3. Verify LCP Echo Request data is echoed back in reply
References:
IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""
https://tools.ietf.org/html/rfc2661
| Test |
Module |
Name |
Synopsis |
L2TP PPP client maintains LCP Magic Number during session |
l2tp-c.tcl |
cdrouter_l2tp_60 |
L2TP PPP client maintains LCP Magic Number during session |
step 1. Terminate the current PPP session using LCP Terminate
step 2. Check for Magic Number in LCP Configure Request
step 3. Wait for LCP Echo Request and verify Magic Number is the same
step 4. Send LCP Echo Request
step 5. Verify Magic Number in LCP Echo Response is the same
RFC 1548 The Point-to-Point Protocol
5.8 Echo-Request and Echo-Reply
NOTE: CDRouter does not fail this test if the L2TP PPP client
does not send an LCP Echo Request. Some clients do not
use LCP Echo Requests automatically.
References:
IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""
https://tools.ietf.org/html/rfc2661
| Test |
Module |
Name |
Synopsis |
L2TP/PPP restarts if PPP authentication fails |
l2tp-c.tcl |
cdrouter_l2tp_200 |
L2TP/PPP restarts if PPP authentication fails |
step 1. Terminate the current PPP session using LCP Terminate
step 2. Verify L2TP client closes current L2TP control session
step 3. Continue to send data from LAN to WAN
step 4. Reject any PAP or CHAP authentication attempts
step 5. Wait 60 seconds, continuing to reject PPP authentication
step 6. Accept PPP authentication after 60 seconds
step 7. Verify PPP link is reestablished in 120 seconds
Note: This test supports PAP and CHAP authentication.
References:
IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""
https://tools.ietf.org/html/rfc2661
| Test |
Module |
Name |
Synopsis |
L2TP/PPP can recover if LCP renegotiation is attempted |
l2tp-c.tcl |
cdrouter_l2tp_210 |
L2TP/PPP can recover if LCP renegotiation is attempted |
step 1. Send LCP config request to PPP peer
step 2. Verify peer resends LCP configuration
step 3. Verify the configuration is the same
step 4. Verify ping succeeds from LAN to WAN
NOTE: Renegotiating LCP has can cause some PPP implementations to terminate
the PPP link or the L2TP link. This test does not fail the DUT if this
happens, but it does issue a warning if the L2TP session is restarted.
References:
IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""
https://tools.ietf.org/html/rfc2661
| Test |
Module |
Name |
Synopsis |
L2TP/PPP can recover if LCP Echo Request contains bad length |
l2tp-c.tcl |
cdrouter_l2tp_230 |
L2TP/PPP can recover if LCP Echo Request contains bad length |
step 1. Send LCP Echo Request with length 4096, but no data
step 2. Peer may respond or drop LCP Echo Request
step 3. Verify PPP is still functioning using ICMP Echo Request
NOTE: This test checks that the device under test behaves gracefully
when it receives PPP options with a bad length. Some devices may
still respond to the LCP Echo Request, but its not considered a failure if
the device does not respond.
References:
IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""
https://tools.ietf.org/html/rfc2661
chap.tcl
PPP CHAP tests for PPP based protocols on the WAN (PPPoE and PPTP)
| Test |
Module |
Name |
Synopsis |
PPP CHAP authentication with various size key lengths |
chap.tcl |
cdrouter_chap_10 |
PPP CHAP authentication with various size key lengths |
step 1. Terminate the current PPP session using LCP Terminate
step 2. Set the new CHAP secret length to a new value (24 37 78 112 255)
step 3. Verify PPPoE, PPTP, or L2TP client restarts the link
step 4. Once LCP is up, send a new CHAP Challenge to peer
step 5. Verify correct CHAP Response is received
step 6. Repeat for each key length generating a new secret each time
References:
IETF RFC 1994 "PPP Challenge Handshake Authentication Protocol (CHAP)"
https://tools.ietf.org/html/rfc1994
| Test |
Module |
Name |
Synopsis |
Verify PPP client will reauthenticate using CHAP during active connection |
chap.tcl |
cdrouter_chap_20 |
Verify PPP client will reauthenticate using CHAP during active connection |
step 1. Send CHAP Challenge to PPP client
step 2. Verify CHAP Response is received in 10 seconds
step 3. Repeat for 30 CHAP Challenges will link remains active
References:
IETF RFC 1994 "PPP Challenge Handshake Authentication Protocol (CHAP)"
https://tools.ietf.org/html/rfc1994
dhcp-s.tcl
DHCP server tests for the LAN side of the router
| Test |
Module |
Name |
Synopsis |
Verify DHCP server returns same IP address when client renews |
dhcp-s.tcl |
cdrouter_dhcp_server_1 |
Verify DHCP server returns same IP address when client renews |
step 1. Send a DHCPREQUEST for the current IP address
step 2. Verify DHCP server sends DHCPACK
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.2: DHCPREQUEST message
https://tools.ietf.org/html/rfc2131#section-4.3.2
| Test |
Module |
Name |
Synopsis |
Verify DHCP server rejects DHCPREQUESTS with non-offered IP address |
dhcp-s.tcl |
cdrouter_dhcp_server_2 |
Verify DHCP server rejects DHCPREQUESTS with non-offered IP address |
step 1. Send DHCPRELEASE to release DHCP client address on LAN
step 2. Configure DHCP client on LAN to include invalid 'Requested IP
Address' option
step 3. Restart DHCP client on LAN
step 4. Wait for DHCPOFFER from DHCP server and send DHCPREQUEST with
invalid 'Requested IP Address' option configured in step 2
step 5. Verify DHCP server sends DHCPNAK
step 6. Restore original behavior
step 7. Restart DHCP client on LAN and verify that client receives a
valid address
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 3.5: Client parameters in DHCP
https://tools.ietf.org/html/rfc2131#section-3.5
IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.2: DHCPREQUEST message
https://tools.ietf.org/html/rfc2131#section-4.3.2
| Test |
Module |
Name |
Synopsis |
Verify DHCP server address reservations |
dhcp-s.tcl |
cdrouter_dhcp_server_3 |
Verify DHCP server address reservations |
step 1. Build a list of DHCP address reservations
step 2. Start new DHCP client on LAN interface using reserved client MAC
step 3. Verify DHCP client obtains expected reserved IP address
step 4. Repeat for each DHCP address reservation identified in step 1
NOTE: Many DHCP server implementations allow addresses within the DHCP pool
to be reserved for specific clients based on the client's MAC address. This
test verifies that the DHCP server honors any configured client MAC to IP
address reservations as defined by the testvars 'dhcpClientReservedIp'
and 'dhcpClientReservedMac'.
Example for two reserved addresses:
testvar dhcpClientReservedIp1 192.168.1.10
testvar dhcpClientReservedMac1 00:11:22:33:33:44
testvar dhcpClientReservedIp2 192.168.1.15
testvar dhcpClientReservedMac2 00:11:22:33:33:55
| Test |
Module |
Name |
Synopsis |
Verify DHCP server returns IP address within configured pool |
dhcp-s.tcl |
cdrouter_dhcp_server_4 |
Verify DHCP server returns IP address within configured pool |
step 1. Send DHCPRELEASE to release DHCP client address on LAN
step 2. Restart DHCP client on LAN
step 3. Verify DHCP client receives an address from within the configured
DHCP pool
Note: The DHCP pool is configured using the testvars dhcpClientStart and
dhcpClientEnd. These testvars must match the DHCP pool settings on the
DUT.
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol"
https://tools.ietf.org/html/rfc2131
| Test |
Module |
Name |
Synopsis |
Verify DHCP server returns IP address with expected lease time |
dhcp-s.tcl |
cdrouter_dhcp_server_5 |
Verify DHCP server returns IP address with expected lease time |
step 1. Send DHCPRELEASE to release DHCP client address on LAN
step 2. Restart DHCP client on LAN
step 3. Verify DHCP client receives an address with the expected lease time
Note: The expected DHCP lease time is configured using the testvar
dhcpClientLeaseTime. This testvar should match the value configured on the
DUT's DHCP server.
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol"
https://tools.ietf.org/html/rfc2131
| Test |
Module |
Name |
Synopsis |
Verify DHCP server returns same IP address when client restarts |
dhcp-s.tcl |
cdrouter_dhcp_server_6 |
Verify DHCP server returns same IP address when client restarts |
step 1. Send DHCPDISCOVER to restart DHCP client on LAN
step 2. Verify DHCP client receives the same IP address
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.1: DHCPDISCOVER message
When a server receives a DHCPDISCOVER message from a client, the
server chooses a network address for the requesting client. If no
address is available, the server may choose to report the problem to
the system administrator. If an address is available, the new address
SHOULD be chosen as follows:
* The client's current address as recorded in the client's current
binding, ELSE
* The client's previous address as recorded in the client's (now
expired or released) binding, if that address is in the server's
pool of available addresses and not already allocated, ELSE
* The address requested in the 'Requested IP Address' option, if that
address is valid and not already allocated, ELSE
* A new address allocated from the server's pool of available
addresses; the address is selected based on the subnet from which
the message was received (if 'giaddr' is 0) or on the address of
the relay agent that forwarded the message ('giaddr' when not 0).
https://tools.ietf.org/html/rfc2131#section-4.3.1
| Test |
Module |
Name |
Synopsis |
Verify DHCP server returns same IP address when client releases then restarts |
dhcp-s.tcl |
cdrouter_dhcp_server_7 |
Verify DHCP server returns same IP address when client releases then restarts |
step 1. Send DHCPRELEASE to release DHCP client address on LAN
step 2. Send DHCPDISCOVER to restart DHCP client on LAN
step 3. Verify DHCP client receives the same IP address
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.1: DHCPDISCOVER message
When a server receives a DHCPDISCOVER message from a client, the
server chooses a network address for the requesting client. If no
address is available, the server may choose to report the problem to
the system administrator. If an address is available, the new address
SHOULD be chosen as follows:
* The client's current address as recorded in the client's current
binding, ELSE
* The client's previous address as recorded in the client's (now
expired or released) binding, if that address is in the server's
pool of available addresses and not already allocated, ELSE
* The address requested in the 'Requested IP Address' option, if that
address is valid and not already allocated, ELSE
* A new address allocated from the server's pool of available
addresses; the address is selected based on the subnet from which
the message was received (if 'giaddr' is 0) or on the address of
the relay agent that forwarded the message ('giaddr' when not 0).
https://tools.ietf.org/html/rfc2131#section-4.3.1
| Test |
Module |
Name |
Synopsis |
Verify DHCP server returns same IP address when client restarts using Requested IP Address option |
dhcp-s.tcl |
cdrouter_dhcp_server_8 |
Verify DHCP server returns same IP address when client restarts using Requested IP Address option |
step 1. Configure DHCP client to use Requested IP Address option (DHCP
option 50) with current IP address as value
step 2. Send DHCPDISCOVER to restart DHCP client on LAN
step 3. Verify DHCP client receives the same IP address
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.1: DHCPDISCOVER message
When a server receives a DHCPDISCOVER message from a client, the
server chooses a network address for the requesting client. If no
address is available, the server may choose to report the problem to
the system administrator. If an address is available, the new address
SHOULD be chosen as follows:
* The client's current address as recorded in the client's current
binding, ELSE
* The client's previous address as recorded in the client's (now
expired or released) binding, if that address is in the server's
pool of available addresses and not already allocated, ELSE
* The address requested in the 'Requested IP Address' option, if that
address is valid and not already allocated, ELSE
* A new address allocated from the server's pool of available
addresses; the address is selected based on the subnet from which
the message was received (if 'giaddr' is 0) or on the address of
the relay agent that forwarded the message ('giaddr' when not 0).
https://tools.ietf.org/html/rfc2131#section-4.3.1
| Test |
Module |
Name |
Synopsis |
Verify DHCP server returns same IP address when client releases and restarts using Requested IP Address option |
dhcp-s.tcl |
cdrouter_dhcp_server_9 |
Verify DHCP server returns same IP address when client releases and restarts using Requested IP Address option |
step 1. Configure DHCP client to use Requested IP Address option (DHCP
option 50) with current IP address as value
step 2. Send DHCPRELEASE to release DHCP client address on LAN
step 3. Send DHCPDISCOVER to restart DHCP client on LAN using Requested IP
Address option in DHCPDISCOVER
step 4. Verify DHCP client receives the same IP address
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.1: DHCPDISCOVER message
When a server receives a DHCPDISCOVER message from a client, the
server chooses a network address for the requesting client. If no
address is available, the server may choose to report the problem to
the system administrator. If an address is available, the new address
SHOULD be chosen as follows:
* The client's current address as recorded in the client's current
binding, ELSE
* The client's previous address as recorded in the client's (now
expired or released) binding, if that address is in the server's
pool of available addresses and not already allocated, ELSE
* The address requested in the 'Requested IP Address' option, if that
address is valid and not already allocated, ELSE
* A new address allocated from the server's pool of available
addresses; the address is selected based on the subnet from which
the message was received (if 'giaddr' is 0) or on the address of
the relay agent that forwarded the message ('giaddr' when not 0).
https://tools.ietf.org/html/rfc2131#section-4.3.1
| Test |
Module |
Name |
Synopsis |
Verify DHCP server returns requested IP address when new client uses Requested IP Address option |
dhcp-s.tcl |
cdrouter_dhcp_server_10 |
Verify DHCP server returns requested IP address when new client uses Requested IP Address option |
step 1. Create a new host with a unique MAC address on the LAN
step 2. Configure new host to use Requested IP Address option (DHCP option
50) with a valid, unallocated address from within the configured LAN
DHCP pool
step 3. Start DHCP client on new host
step 4. Verify DHCP client receives the address included in the Requested
IP Address option
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.1: DHCPDISCOVER message
When a server receives a DHCPDISCOVER message from a client, the
server chooses a network address for the requesting client. If no
address is available, the server may choose to report the problem to
the system administrator. If an address is available, the new address
SHOULD be chosen as follows:
* The client's current address as recorded in the client's current
binding, ELSE
* The client's previous address as recorded in the client's (now
expired or released) binding, if that address is in the server's
pool of available addresses and not already allocated, ELSE
* The address requested in the 'Requested IP Address' option, if that
address is valid and not already allocated, ELSE
* A new address allocated from the server's pool of available
addresses; the address is selected based on the subnet from which
the message was received (if 'giaddr' is 0) or on the address of
the relay agent that forwarded the message ('giaddr' when not 0).
https://tools.ietf.org/html/rfc2131#section-4.3.1
| Test |
Module |
Name |
Synopsis |
Verify DHCP server does not return an address when invalid Requested IP Address option is used |
dhcp-s.tcl |
cdrouter_dhcp_server_11 |
Verify DHCP server does not return an address when invalid Requested IP Address option is used |
step 1. Create a new host with a unique MAC address on the LAN
step 2. Configure new host to use Requested IP Address option (DHCP option
50) with the IP address of the existing LAN interface
step 3. Start DHCP client on new host
step 4. Verify DHCP client does not receive the address included in the
Requested IP Address option since it has already been allocated
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.1: DHCPDISCOVER message
When a server receives a DHCPDISCOVER message from a client, the
server chooses a network address for the requesting client. If no
address is available, the server may choose to report the problem to
the system administrator. If an address is available, the new address
SHOULD be chosen as follows:
* The client's current address as recorded in the client's current
binding, ELSE
* The client's previous address as recorded in the client's (now
expired or released) binding, if that address is in the server's
pool of available addresses and not already allocated, ELSE
* The address requested in the 'Requested IP Address' option, if that
address is valid and not already allocated, ELSE
* A new address allocated from the server's pool of available
addresses; the address is selected based on the subnet from which
the message was received (if 'giaddr' is 0) or on the address of
the relay agent that forwarded the message ('giaddr' when not 0).
https://tools.ietf.org/html/rfc2131#section-4.3.1
| Test |
Module |
Name |
Synopsis |
DHCP server includes vendor defined options |
dhcp-s.tcl |
cdrouter_dhcp_server_30 |
DHCP server includes vendor defined options |
step 1. Send DHCPRELEASE to release DHCP client address on LAN
step 2. Send DHCPDISCOVER to restart DHCP client on LAN
step 3. Verify DHCP client receives the expected options
The testvars lanDhcpClientOptionCode and lanDhcpClientOptionData can
be used to configure a list of DHCP options that the client should
receive from the DHCP server.
| Test |
Module |
Name |
Synopsis |
Verify server supports DHCP Rapid Commit option |
dhcp-s.tcl |
cdrouter_dhcp_server_31 |
Verify server supports DHCP Rapid Commit option |
step 1. Send DHCPRELEASE to release DHCP client address on LAN
step 2. Configure DHCP client on LAN to use the Rapid Commit option
step 3. Restart DHCP client on LAN
step 4. Wait for DHCPACK from DHCP server
step 5. Verify DHCP server sends DHCPACK including Rapid Commit option
step 6. Verify DHCP client receives a valid address
step 7. Restore original behavior
step 8. Restart DHCP client on LAN and verify that client receives a
valid address
References:
IETF RFC 4039 "Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4)" Section 3.1: Client/Server Operation
https://tools.ietf.org/html/rfc4039#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify DHCP server ignores DHCPDISCOVER messages on port 68 |
dhcp-s.tcl |
cdrouter_dhcp_server_35 |
Verify DHCP server ignores DHCPDISCOVER messages on port 68 |
step 1. Send DHCPRELEASE to release DHCP client address on LAN
step 2. Send DHCPDISCOVER to LAN DHCP server using port 68
step 3. Verify DHCP server ignores the DHCPDISCOVER.
step 4. Restart DHCP client on LAN allowing the client to obtain an address
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.1: Constructing and sending DHCP messages
https://tools.ietf.org/html/rfc2131#section-4.1
| Test |
Module |
Name |
Synopsis |
Verify DHCP server accepts DHCP client packets with IPv4 length less than 576 |
dhcp-s.tcl |
cdrouter_dhcp_server_100 |
Verify DHCP server accepts DHCP client packets with IPv4 length less than 576 |
step 1. Send DHCPRELEASE to release DHCP client address on LAN
step 2. Configure DHCP client on LAN to not use minimum size DHCP packets
step 3. Restart DHCP client on LAN
step 4. Verify DHCP client receives a valid address
step 5. Restore original behavior
step 6. Restart DHCP client on LAN and verify that client receives a
valid address
NOTE: RFC 2131 allows clients to send DHCP packets that are not padded
out to a minimum length. Older servers based on RFC 1541 may require
a minimum IP length of 576 for DHCP packets. This test verifies that the
DHCP server will interoperate with newer clients based on RFC 2131.
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 2: Protocol Summary
https://tools.ietf.org/html/rfc2131#section-2
| Test |
Module |
Name |
Synopsis |
Verify DHCP server rejects DHCPREQUESTS with IP address of other clients |
dhcp-s.tcl |
cdrouter_dhcp_server_200 |
Verify DHCP server rejects DHCPREQUESTS with IP address of other clients |
step 1. Create a new DHCP client on LAN
step 2. Verify new client obtains a valid IP address
step 3. Attempt to renew the new client's lease using the IP address of
another client in 'Client IP Address' option
step 4. Verify DHCP server sends DHCPNAK
step 5. Remove DHCP client created in step 1 from LAN
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 3.5: Client parameters in DHCP
https://tools.ietf.org/html/rfc2131#section-3.5
IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.2: DHCPREQUEST message
https://tools.ietf.org/html/rfc2131#section-4.3.2
| Test |
Module |
Name |
Synopsis |
Verify DHCP server ignores site-specific DHCP options |
dhcp-s.tcl |
cdrouter_dhcp_server_300 |
Verify DHCP server ignores site-specific DHCP options |
step 1. Send DHCPRELEASE to release DHCP client address on LAN
step 2. Configure DHCP client on LAN to include site specific options
step 3. Restart DHCP client on LAN
step 4. Verify DHCP client receives a valid address
step 5. Restore original behavior
step 6. Restart DHCP client on LAN and verify that client receives a
valid address
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 3.5: Client parameters in DHCP
https://tools.ietf.org/html/rfc2131#section-3.5
| Test |
Module |
Name |
Synopsis |
Verify DHCP server handles client option with length 0 |
dhcp-s.tcl |
cdrouter_dhcp_server_301 |
Verify DHCP server handles client option with length 0 |
step 1. Send DHCPRELEASE to release DHCP client address on LAN
step 2. Configure DHCP client on LAN to include a 0 length option
step 3. Restart DHCP client on LAN
step 4. Verify DHCP client receives a valid address
step 5. Restore original behavior
step 6. Restart DHCP client on LAN and verify that client receives a
valid address
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 3.5: Client parameters in DHCP
https://tools.ietf.org/html/rfc2131#section-3.5
| Test |
Module |
Name |
Synopsis |
Verify DHCP server ignores DHCP packets with an invalid UDP checksum |
dhcp-s.tcl |
cdrouter_dhcp_server_401 |
Verify DHCP server ignores DHCP packets with an invalid UDP checksum |
step 1. Send DHCPRELEASE to release DHCP client address on LAN
step 2. Configure DHCP client on LAN to send corrupted UDP checksums
step 3. Restart DHCP client on LAN
step 4. Verify DHCP client does not receive a valid address
step 5. Restore original behavior
step 6. Restart DHCP client on LAN and verify that client receives a
valid address
| Test |
Module |
Name |
Synopsis |
Verify DHCP server allows multiple DHCP clients with same name (DHCP option 12) |
dhcp-s.tcl |
cdrouter_dhcp_server_501 |
Verify DHCP server allows multiple DHCP clients with same name (DHCP option 12) |
step 1. Create a new DHCP client on LAN
step 2. Configure new client with the same hostname as the primary LAN client
step 3. Verify new client obtains a valid IP address
step 4. Remove DHCP client created in step 1 from LAN
Note: This test checks that two DHCP clients configured with the same
hostname can still receive a DHCP address. The hostname is set using
DHCP Option 12.
| Test |
Module |
Name |
Synopsis |
Verify DHCP server uses IPv4 broadcast when DHCP client sets broadcast flag |
dhcp-s.tcl |
cdrouter_dhcp_server_520 |
Verify DHCP server uses IPv4 broadcast when DHCP client sets broadcast flag |
step 1. Send DHCPRELEASE to release DHCP client address on LAN
step 2. Configure DHCP client on LAN to set the broadcast bit in
its DHCPDISCOVER message
step 3. Restart DHCP client on LAN
step 4. Verify DHCP client receives a valid address
step 5. Restore original behavior
step 6. Restart DHCP client on LAN and verify that client receives a
valid address
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 2: Protocol Summary
https://tools.ietf.org/html/rfc2131#section-2
IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.1: Constructing and sending DHCP messages
https://tools.ietf.org/html/rfc2131#section-4.1
| Test |
Module |
Name |
Synopsis |
Verify DHCP server probes IPv4 client address before assigning |
dhcp-s.tcl |
cdrouter_dhcp_server_540 |
Verify DHCP server probes IPv4 client address before assigning |
step 1. Create a new DHCP client on LAN
step 2. Watch all ARP and ICMP Echo requests from the router's LAN interface
step 3. Verify DHCP client receives a valid address
step 4. Verify router and/or DHCP server sends ARP or ICMP Echo request
for DHCP client's address before assigning it
step 5. Remove DHCP client created in step 1 from LAN
NOTE: Each DHCP server may use a different technique to probe
an IPv4 address before assigning it to a client. For example,
send an ARP Request, ICMP ping, etc. This test verifies that
the router attempts to resolve an ARP Request for the IPv4
address or send an ICMP Echo Request before the address is
assigned to a DHCP client.
NOTE: In most cases the default router and DHCP server will be the same
IPv4 address. However, this test allows them to be different.
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 3.1: Client-Server Interaction
https://tools.ietf.org/html/rfc2131#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify DHCP server returns correct WINS server(s) |
dhcp-s.tcl |
cdrouter_dhcp_server_600 |
Verify DHCP server returns correct WINS server(s) |
step 1. Send DHCPRELEASE to release DHCP client address on LAN
step 2. Configure DHCP client on LAN to request WINS server option
step 3. Restart DHCP client on LAN
step 4. Verify DHCP client receives a valid address that includes the WINS
server option
step 5. Verify WINS server address(es) provided by the DHCP server match
the expected value(s)
step 6. Restore original behavior
step 7. Restart DHCP client on LAN and verify that client receives a
valid address
| Test |
Module |
Name |
Synopsis |
Verify DHCP server returns correct NTP server(s) |
dhcp-s.tcl |
cdrouter_dhcp_server_610 |
Verify DHCP server returns correct NTP server(s) |
step 1. Send DHCPRELEASE to release DHCP client address on LAN
step 2. Configure DHCP client on LAN to request NTP server option
step 3. Restart DHCP client on LAN
step 4. Verify DHCP client receives a valid address that includes the NTP
server option
step 5. Verify NTP server address(es) provided by the DHCP server match
the expected value(s)
step 6. Restore original behavior
step 7. Restart DHCP client on LAN and verify that client receives a
valid address
NOTE: CDRouter automatically announces ntpServer1 and ntpServer2
via DHCP on the WAN. This test verifies that the NTP server(s)
received via DHCP on the LAN match the ntpServer1 and ntpServer2
addresses. If both ntpServer1 and ntpServer2 are configured, this
test will verify that the LAN client received both addresses. If
only one NTP server is configured, this test will verify that the
LAN client received only the expected address. This test is only
run if the testvar 'dhcpClientRequestNtp' is set to 'yes'.
| Test |
Module |
Name |
Synopsis |
Verify DHCP server returns correct client identifier option |
dhcp-s.tcl |
cdrouter_dhcp_server_620 |
Verify DHCP server returns correct client identifier option |
step 1. Send DHCPRELEASE to release DHCP client address on LAN
step 2. Configure DHCP client on LAN to request the 'client identifier'
option
step 3. Restart DHCP client on LAN
step 4. Verify DHCP client receives client identifier option in all
DHCP response packets from the server
step 5. Verify client identifier option contains client's MAC address
step 6. Verify DHCP client receives IP address
If the 'client identifier' option is present in a message received
from a client, the server MUST return the 'client identifier' option,
unaltered, in its response message.
References:
IETF RFC 6842 "Client Identifier Option in DHCP Server Replies" Section 3: Modification to RFC 2131
https://tools.ietf.org/html/rfc6842#section-3
| Test |
Module |
Name |
Synopsis |
Verify DHCP server returns correct DNS server(s) |
dhcp-s.tcl |
cdrouter_dhcp_server_630 |
Verify DHCP server returns correct DNS server(s) |
step 1. Send DHCPRELEASE to release DHCP client address on LAN
step 2. Configure DHCP client on LAN to request DNS server option
step 3. Restart DHCP client on LAN
step 4. Verify DHCP client receives a valid address that includes the DNS
server option
step 5. Verify DNS server address(es) provided by the DHCP server match
the expected value(s)
NOTE: CDRouter automatically announces wanDnsServer, wanBackupDnsServer, and
optionally wanBackupDnsServer2 and wanBackupDnsServer3 via DHCP on the WAN.
If the testvar “DNStoDHCP“ is set to “yes”, CDRouter will verify that its
LAN DHCP client receives the same DNS servers that have either been learned
dynamically by the DUT on the WAN or configured manually on the DUT. If the
testvar “DNStoDHCP” is set to “no”, CDRouter will verify that its LAN DHCP
client receives the DNS server specified by the testvar “lanDnsServer”
instead.
| Test |
Module |
Name |
Synopsis |
Verify DHCP server responds to unicast and broadcast DHCPINFORM messages |
dhcp-s.tcl |
cdrouter_dhcp_server_700 |
Verify DHCP server responds to unicast and broadcast DHCPINFORM messages |
step 1. Send a unicast DHCPINFORM message to the DHCP server
including DNS Servers (Option 6) and Domain Name (Option 15)
in the parameter request list
step 2. Verify DHCP server sends DHCPACK
step 3. Verify the DHCPACK does not contain a lease time
step 4. Verify the DHCPACK contains the correct DNS servers (Option 6)
step 5. Verify the DHCPACK contains the correct domain name (Option 15)
NOTE: Domain Name is only checked when the wanMode is DHCP
and if the testvar lanDomainName is not set to 'none'.
step 6. Repeat test by sending broadcast DHCPINFOM message
NOTE: If your DUT does not respond with the Domain Name DHCP option (15),
then ensure that the testvar lanDomainName is set to the keyword 'none'.
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 3.4: Obtaining parameters with externally configured network address
https://tools.ietf.org/html/rfc2131#section-3.4
| Test |
Module |
Name |
Synopsis |
Verify DHCP server handles clients using V-I Vendor-Specific Information option |
dhcp-s.tcl |
cdrouter_dhcp_server_710 |
Verify DHCP server handles clients using V-I Vendor-Specific Information option |
step 1. Send DHCPRELEASE to release DHCP client address on LAN
step 2. Configure DHCP client on LAN to request V-I Vendor-Specific
Information option
step 3. Restart DHCP client on LAN
step 4. Verify DHCP client receives a valid address
step 5. Restore original behavior
step 6. Restart DHCP client on LAN and verify that client receives a
valid address
NOTE: This test verifies that new LAN side CPE devices with TR-111 support
can still operate behind an IGD device that may not support TR-069. The IGD
device should ignore the unknown DHCP options if they are not supported.
References:
IETF RFC 3925 "Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)"
https://tools.ietf.org/html/rfc3925
| Test |
Module |
Name |
Synopsis |
Verify DHCP server handles clients using V-I Vendor Class option |
dhcp-s.tcl |
cdrouter_dhcp_server_720 |
Verify DHCP server handles clients using V-I Vendor Class option |
step 1. Send DHCPRELEASE to release DHCP client address on LAN
step 2. Configure DHCP client on LAN to request V-I Vendor Class option
step 3. Restart DHCP client on LAN
step 4. Verify DHCP client receives a valid address
step 5. Restore original behavior
step 6. Restart DHCP client on LAN and verify that client receives a
valid address
NOTE: This test verifies that new LAN side CPE devices using Vendor Class
options to identify themselves can still operate behind an IGD device
that may not recognize Vendor Class options.
References:
IETF RFC 3925 "Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)"
https://tools.ietf.org/html/rfc3925
| Test |
Module |
Name |
Synopsis |
Verify DHCP server does not become exhausted after a large number of DHCP restarts |
dhcp-s.tcl |
cdrouter_dhcp_server_800 |
Verify DHCP server does not become exhausted after a large number of DHCP restarts |
step 1. Send DHCPDISCOVER to restart DHCP client on LAN
step 2. Verify DHCP client receives an address from within the configured
DHCP pool
step 3. Repeat steps 1 and 2 N times, where N is equal to 2 times the DHCP
pool size
Note: The DHCP pool is configured using the testvars dhcpClientStart and
dhcpClientEnd. These testvars must match the DHCP pool settings on the
DUT.
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol"
https://tools.ietf.org/html/rfc2131
| Test |
Module |
Name |
Synopsis |
Verify DHCP server does not become exhausted after a large number of DHCP release then restarts |
dhcp-s.tcl |
cdrouter_dhcp_server_801 |
Verify DHCP server does not become exhausted after a large number of DHCP release then restarts |
step 1. Send DHCPRELEASE to release DHCP client address on LAN
step 2. Send DHCPDISCOVER to restart DHCP client on LAN
step 3. Verify DHCP client receives an address from within the configured
DHCP pool
step 4. Repeat steps 1 through 3 N times, where N is equal to 2 times the
DHCP pool size
Note: The DHCP pool is configured using the testvars dhcpClientStart and
dhcpClientEnd. These testvars must match the DHCP pool settings on the
DUT.
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol"
https://tools.ietf.org/html/rfc2131
nat.tcl
NAPT tests for TCP, UDP, and ICMP
| Test |
Module |
Name |
Synopsis |
Outbound TCP connections use NAPT |
nat.tcl |
cdrouter_nat_1 |
Outbound TCP connections use NAPT |
step 1. Initiate an outbound TCP connection to HTTP server
step 2. Verify the connection is established
step 3. Send HTTP GET request to server
step 4. Verify HTTP response is received
step 5. Verify the IPv4 source address on the WAN side is the router's address
step 6. Close TCP connection from LAN side
References:
IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"
https://tools.ietf.org/html/rfc3022
| Test |
Module |
Name |
Synopsis |
Outbound UDP connections use NAPT |
nat.tcl |
cdrouter_nat_2 |
Outbound UDP connections use NAPT |
step 1. Initiate an outbound UDP connection (UDP Echo)
step 2. Verify the udp is received on WAN side
step 3. Verify the IPv4 source address on the WAN side is the router's address
step 4. Send a return response back to LAN
step 5. Verify return packet is received on the LAN
References:
IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"
https://tools.ietf.org/html/rfc3022
| Test |
Module |
Name |
Synopsis |
Maximum number of TCP connections with single LAN host |
nat.tcl |
cdrouter_nat_100 |
Maximum number of TCP connections with single LAN host |
step 1. Initiate an outbound TCP connection
step 2. Verify the connection is established
step 3. Send HTTP GET on TCP connection
step 4. Verify the source address on the WAN side is the router's address
step 5. Continue creating sessions up to the maximum number supported
References:
IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"
https://tools.ietf.org/html/rfc3022
| Test |
Module |
Name |
Synopsis |
NAPT with multiple LAN hosts using the same TCP source port |
nat.tcl |
cdrouter_nat_101 |
NAPT with multiple LAN hosts using the same TCP source port |
step 1. Configure additional LAN host
step 2. Configure the new LAN host so that its TCP source ports will be the
same as the original LAN host
step 3. Initiate outbound TCP connections for both LAN hosts
step 4. Verify the connections are established
step 5. Continue to create up to 10 connections per host
References:
IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"
https://tools.ietf.org/html/rfc3022
| Test |
Module |
Name |
Synopsis |
NAPT with a TCP and UDP connection using the same source port |
nat.tcl |
cdrouter_nat_120 |
NAPT with a TCP and UDP connection using the same source port |
step 1. Initiate an outbound TCP connection to HTTP server
step 2. Verify the connection is established
step 3. Verify the IPv4 source address on the WAN side is the router's address
step 4. Initiate an outbound UDP connection using same source port (UDP Echo)
step 5. Verify the UDP packet is received on the WAN
step 6. Send a return UDP packet back to the LAN host
step 7. Verify return UDP packet is received on the LAN
step 8. Close TCP connection from LAN side
References:
IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"
https://tools.ietf.org/html/rfc3022
| Test |
Module |
Name |
Synopsis |
Verify NAPT with outbound TCP connections using high and low source ports |
nat.tcl |
cdrouter_nat_130 |
Verify NAPT with outbound TCP connections using high and low source ports |
step 1. Set the next TCP source port to 65535
step 2. Initiate an outbound TCP connection to HTTP server
step 3. Verify the connection is established
step 4. Verify the IPv4 source address on the WAN side is the router's address
step 5. Send HTTP GET request to server
step 6. Verify HTTP response is received
step 7. Close TCP connection from LAN side
step 8. Repeat using TCP source ports 65534, 0, 1, and 2
References:
IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"
https://tools.ietf.org/html/rfc3022
| Test |
Module |
Name |
Synopsis |
Verify TCP source port can be reused after a passive close behind NAPT |
nat.tcl |
cdrouter_nat_150 |
Verify TCP source port can be reused after a passive close behind NAPT |
step 1. Initiate an outbound TCP connection to TCP server
step 2. Verify the connection is established and operational
step 3. Initiate a TCP active close from the WAN side
step 4. Initiate a TCP passive close from the LAN side
step 5. Initiate a new outbound TCP connection using the same TCP source port
step 6. Verify the connection is established and operational
NOTES: The NAPT implementation should allow new TCP connections to reuse the
same source port if the TCP connection on the LAN side is closed through
a passive TCP close operation.
The amount of time to wait before attempting to resue the Tcp port can
be configured using testvar 'natTcpPortDelay'. It defaults to 1 second. Setting
this value too high may defeat the test since the port mapping may be
deleted before the port is reused.
References:
IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"
https://tools.ietf.org/html/rfc3022
| Test |
Module |
Name |
Synopsis |
Maximum number of UDP connections with single LAN host |
nat.tcl |
cdrouter_nat_200 |
Maximum number of UDP connections with single LAN host |
step 1. Initiate an outbound UDP connection
step 2. Verify the the UDP packet is received on the WAN
step 3. Verify the source address on the WAN side is the router's address
step 4. Send return UDP packet back to the LAN
step 5. Verify the return UDP packet is received on the LAN
step 6. Continue creating sessions up to the maximum number supported
step 7. Once all sessions are established, loop through each session
again and forward a UDP packet from the WAN to the LAN using
the port mappings that were established for each connection
step 8. Verify that each UDP connection is still forwarding traffic
from WAN to LAN.
References:
IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"
https://tools.ietf.org/html/rfc3022
| Test |
Module |
Name |
Synopsis |
NAPT with multiple LAN hosts using the same UDP source port |
nat.tcl |
cdrouter_nat_201 |
NAPT with multiple LAN hosts using the same UDP source port |
step 1. Configure additional LAN host
step 2. Configure the new LAN host so that its UDP source ports will be the
same as the original LAN host
step 3. Initiate outbound UDP connections for both LAN hosts (UDP Echo)
step 4. Verify the UDP Echo requests are answered
step 5. Continue to create up to 10 UDP connections per host
References:
IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"
https://tools.ietf.org/html/rfc3022
| Test |
Module |
Name |
Synopsis |
Verify NAPT checks source IP address of inbound UDP packets |
nat.tcl |
cdrouter_nat_300 |
Verify NAPT checks source IP address of inbound UDP packets |
step 1. Forward a UDP packet from a LAN client to the WAN
step 2. Forward a packet back from the WAN to the same LAN client
step 3. Verify packet is received
step 4. Forward a packet using a different source IP address to LAN
step 5. Verify the packet is not forwarded onto the LAN or if
the natType or dsliteFirewallMode is full-cone, verify
the packet is forwarded to the LAN.
NOTE: The exact behavior of this test depends on the type of NAT that
is implemented by the device. The testvar natMode can be used to
configure either full-cone, address-restricted, or port-restricted NAT.
NOTE: When DS-Lite is enabled, NAT is not normally applied on the CPE.
The CPE may still apply a firewall. The mode of the firewall can be
configured using the dsliteFirewallMode testvar.
References:
IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"
https://tools.ietf.org/html/rfc3022
| Test |
Module |
Name |
Synopsis |
UDP headers with a checksum equal to 0 should not be modified |
nat.tcl |
cdrouter_nat_320 |
UDP headers with a checksum equal to 0 should not be modified |
step 1. Forward a UDP packet from a LAN client to the WAN with
UDP checksum equal to 0
step 2. Verify packet is received
step 3. Verify received UDP checksum on WAN side is 0
References:
IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)" Section 4.1: IP, TCP, UDP and ICMP Header Manipulations
https://tools.ietf.org/html/rfc3022#section-4.1
| Test |
Module |
Name |
Synopsis |
Outbound TCP connection using IPv4 options |
nat.tcl |
cdrouter_nat_330 |
Outbound TCP connection using IPv4 options |
step 1. Enable LAN client and remote host to include the router alert
IP option in every IPv4 packet
step 2. Initiate an outbound TCP connection to HTTP server
step 3. Verify the connection is established
step 4. Verify the IPv4 source address on the WAN side is the router's address
step 5. Send HTTP GET request to server
step 6. Verify HTTP response is received
step 7. Close TCP connection from LAN side
References:
IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"
https://tools.ietf.org/html/rfc3022
| Test |
Module |
Name |
Synopsis |
Outbound UDP connection using IPv4 options |
nat.tcl |
cdrouter_nat_340 |
Outbound UDP connection using IPv4 options |
step 1. Enable LAN client and remote host to include the router alert
IP option every IPv4 packet
step 2. Initiate an outbound UDP connection (UDP Echo)
step 3. Verify the UDP is received on WAN side
step 4. Verify the IPv4 source address on the WAN side is the router's address
step 5. Send a return response back to LAN
step 6. Verify return packet is received on the LAN
References:
IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"
https://tools.ietf.org/html/rfc3022
| Test |
Module |
Name |
Synopsis |
Verify NAPT uses port parity preservation |
nat.tcl |
cdrouter_nat_350 |
Verify NAPT uses port parity preservation |
step 1. Send UDP packet from LAN to WAN
step 2. Verify UDP packet is received on the WAN
step 3. Verify source port on WAN matches the parity of original LAN port
step 4. Repeat for incremental ports
If port parity is not supported, this test can be skipped by configuring
the testvar 'natPortParity' to 'no'. The default is yes.
References:
IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 4.2.2: Port Parity
https://tools.ietf.org/html/rfc4787#section-4.2.2
| Test |
Module |
Name |
Synopsis |
Verify ICMP Destination Unreachable message from WAN does not destroy NAT UDP mapping |
nat.tcl |
cdrouter_nat_360 |
Verify ICMP Destination Unreachable message from WAN does not destroy NAT UDP mapping |
step 1. Send UDP packet from LAN to WAN
step 2. Verify UDP packet is received on the WAN and return an ICMP Destination Unreachable message
step 3. Verify ICMP Destination Unreachable message is received on the LAN
step 4. Send UDP response from WAN to LAN
step 5. Verify UDP response is received on LAN since NAPT mapping is still working
NOTE: Receipt of any sort of ICMP message must not destroy the NAT mapping.
This is REQ-12 from RFC 4787.
References:
IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 9: ICMP Destination Unreachable Behavior
https://tools.ietf.org/html/rfc4787#section-9
| Test |
Module |
Name |
Synopsis |
Verify ICMP Destination Unreachable message from WAN does not destroy NAT TCP mapping |
nat.tcl |
cdrouter_nat_361 |
Verify ICMP Destination Unreachable message from WAN does not destroy NAT TCP mapping |
step 1. Establish TCP connection from LAN to WAN
step 2. Send an ICMP Destination Unreachable message from the WAN for the connection
step 3. Verify ICMP Destination Unreachable message is received on the LAN
step 4. Send TCP data segment from WAN to LAN for the session
step 5. Verify TCP data segment is received on LAN since NAPT mapping is still working
References:
IETF RFC 5382 "NAT Behavioral Requirements for TCP" Section 7.3: ICMP Responses to TCP Packets
REQ-10: Receipt of any sort of ICMP message MUST NOT terminate the
NAT mapping or TCP connection for which the ICMP was generated.
Justification: This is necessary for reliably performing TCP
simultaneous-open where a remote NAT may temporarily signal an
ICMP error.
https://tools.ietf.org/html/rfc5382#section-7.3
| Test |
Module |
Name |
Synopsis |
Verify basic MSS Clamping for TCP sessions |
nat.tcl |
cdrouter_nat_400 |
Verify basic MSS Clamping for TCP sessions |
step 1. Set the TCP MSS size to 1460
step 2. Initiate an outbound TCP connection to HTTP server
step 3. Verify the received MSS on the LAN and WAN matches
the expected MSS size
step 4. Verify the IPv4 source address on the WAN side is the router's address
step 5. Send HTTP GET request to server
step 6. Verify HTTP response is received
step 7. Close TCP connection from LAN side
NOTE: The expected MSS size for MSS clamping can be configured
using the testvar 'mssClampingValue'. If the inbound direction is
different than the outbound direction for MSS clamping, the inbound
direction can be adjusted using the testvar mssClampingInValue.
NOTE: The TCP port used for the MSS clamping test defaults to
port 8096. This can be changed using the testvar mssClampingTestPort.
| Test |
Module |
Name |
Synopsis |
Verify MSS Clamping with TCP options from different clients |
nat.tcl |
cdrouter_nat_401 |
Verify MSS Clamping with TCP options from different clients |
step 1. Set the TCP options to resemble a Windows TCP client
step 2. Initiate an outbound TCP connection to HTTP server
step 3. Verify the received MSS on the LAN and WAN matches
the expected MSS size
step 4. Verify the IPv4 source address on the WAN side is the router's address
step 5. Send HTTP GET request to server
step 6. Verify HTTP response is received
step 7. Close TCP connection from LAN side
step 8. Repeat testing using TCP options for a Linux TCP client
step 9. Repeat testing using TCP options for a Mac OS X TCP client
NOTE: The expected MSS size for MSS clamping can be configured
using the testvar 'mssClampingValue'. If the inbound direction is
different than the outbound direction for MSS clamping, the inbound
direction can be adjusted using the testvar mssClampingInValue.
NOTE: The TCP port used for the MSS clamping test defaults to
port 8096. This can be changed using the testvar mssClampingTestPort.
| Test |
Module |
Name |
Synopsis |
Verify MSS Clamping does not modify smaller MSS values |
nat.tcl |
cdrouter_nat_410 |
Verify MSS Clamping does not modify smaller MSS values |
step 1. Set the TCP MSS size to 512
step 2. Initiate an outbound TCP connection to HTTP server
step 3. Verify the received MSS on the LAN and WAN is stil 512
step 4. Verify the IPv4 source address on the WAN side is the router's address
step 5. Send HTTP GET request to server
step 6. Verify HTTP response is received
step 7. Close TCP connection from LAN side
NOTE: In order to pass this test, the router's expected MSS Clamping value
must be greater than 512. When the router detects a MSS value smaller than its
own MSS clamping value, it should leave the MSS unchanged. The expected MSS
size for MSS clamping can be configured using the testvar 'mssClampingValue'.
NOTE: The TCP port used for the MSS clamping test defaults to
port 8096. This can be changed using the testvar mssClampingTestPort.
| Test |
Module |
Name |
Synopsis |
NAT uses single binding for TCP session with same source IP and source port |
nat.tcl |
cdrouter_nat_500 |
NAT uses single binding for TCP session with same source IP and source port |
step 1. Initiate an outbound TCP connection to server 1 on the WAN
step 2. Initiate a second outbound TCP connection to server 2 on the WAN
step 3. Verify outgoing source port on the WAN side is the same for both connections
step 4. Close both connections
RFC 3022 Section 3.1 states that NAT implementations may use the same
binding for TCP or UDP sessions when the source IP and port are the same.
This technique is used by peer-to-peer applications to establish a
connection through NAT. This is also known as Cone NAT.
NOTE: IETF draft-ford-midcom-p2p-03.txt
Section 5.1. Deprecate the use of symmetric NATs
This test is only run when the testvar 'natSupportsP2P' is set to yes.
References:
IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)" Section 3.1: Address binding
https://tools.ietf.org/html/rfc3022#section-3.1
IETF Internet-Draft draft-ford-midcom-p2p-03 "Peer-to-Peer(P2P) communication across Network Address Translators(NATs)" Section 5.1: Deprecate the use of symmetric NATs
https://tools.ietf.org/html/draft-ford-midcom-p2p-03#section-5.1
| Test |
Module |
Name |
Synopsis |
NAT uses single binding for UDP session with same source IP and source port |
nat.tcl |
cdrouter_nat_501 |
NAT uses single binding for UDP session with same source IP and source port |
step 1. Initiate an outbound UDP connection to server 1 on the WAN
step 2. Initiate a second outbound UDP connection to server 2 on the WAN
step 3. Verify outgoing source port on the WAN side is the same for both connections
RFC 3022 Section 3.1 states that NAT implementations may use the same
binding for TCP or UDP sessions when the source IP and port are the same.
This technique is used by peer-to-peer applications to establish a
connection through NAT. This is also known as Cone NAT.
NOTE: IETF draft-ford-midcom-p2p-03.txt
Section 5.1. Deprecate the use of symmetric NATs
This test is only run when the testvar 'natSupportsP2P' is set to yes.
References:
IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)" Section 3.1: Address binding
https://tools.ietf.org/html/rfc3022#section-3.1
IETF Internet-Draft draft-ford-midcom-p2p-03 "Peer-to-Peer(P2P) communication across Network Address Translators(NATs)" Section 5.1: Deprecate the use of symmetric NATs
https://tools.ietf.org/html/draft-ford-midcom-p2p-03#section-5.1
| Test |
Module |
Name |
Synopsis |
NAT performs hairpin translation for LAN side TCP connections |
nat.tcl |
cdrouter_nat_510 |
NAT performs hairpin translation for LAN side TCP connections |
step 1. Initiate an outbound TCP connection to server 1 from LAN source port A
step 2. Initiate a second outbound TCP connection to server 1 from LAN source port B
step 3. Detect public IP and source port for both TCP connections
step 4. Send TCP SYN from LAN source port A to public IP and source port for connection 2
step 5. Send TCP SYN from LAN source port B to public IP and source port for connection 1
step 6. Send TCP SYN from LAN source port A to public IP and source port for connection 2
** NOTE: This step is required for Restricted and Port Restricted
Cone NATs. These types of NATs require an existing outgoing session
before allowing incoming packets. The test will pass packets in both
directions before trying to verify the hairpin behavior.
step 7. Verify packet is received at LAN source port B
step 8. Verify source IPv4 address and TCP port are translated to public IPv4 and port
** NOTE: The test only issues a warning if the TCP source port is not preserved.
step 9. Send TCP SYN-ACK from LAN source port B to public IP and source port for connection 1
** NOTE: The source port is taken from the TCP SYN packet to work with implementations
that do not preserve the TCP source port.
step 10. Verify packet is received at LAN source port A
step 11. Verify source IPv4 address and TCP port are translated to public IPv4 and port
NOTES: This test scenario should work for all Cone NAT implementations - Full
Cone NAT, Restricted Cone NAT, and Port Restricted Cone NAT. For a discussion
of each type of Cone NAT, please see RFC 3489.
This test is only run when the testvar 'natSupportsP2P' is set to yes.
References:
IETF RFC 5382 "NAT Behavioral Requirements for TCP" Section 7.2: Hairpinning behavior
https://tools.ietf.org/html/rfc5382#section-7.2
| Test |
Module |
Name |
Synopsis |
NAT performs hairpin translation for LAN side UDP connections |
nat.tcl |
cdrouter_nat_511 |
NAT performs hairpin translation for LAN side UDP connections |
step 1. Initiate an outbound UDP connection to server 1 from LAN source port A
step 2. Initiate a second outbound UDP connection to server 1 from LAN source port B
step 3. Detect public IP and source port for both UDP connections
step 4. Send UDP from LAN source port A to public IP and source port for connection 2
step 5. Send UDP from LAN source port B to public IP and source port for connection 1
step 6. Send UDP from LAN source port A to public IP and source port for connection 2
** NOTE: This step is required for Restricted and Port Restricted
Cone NATs. These types of NATs require an existing outgoing session
before allowing incoming packets. The test will pass packets in both
directions before trying to verify the hairpin behavior.
step 7. Verify packet is received at LAN source port B
step 8. Verify source IPv4 address and UDP port are translated to public IPv4 and port
** NOTE: The test only issues a warning if the UDP source port is not preserved.
step 9. Send UDP from LAN source port B to public IP and source port for connection 1
** NOTE: The source port is taken from the incoming UDP packet to work with
implementations that do not preserve the UDP source port.
step 10. Verify packet is received at LAN source port A
step 11. Verify source IPv4 address and UDP port are translated to public IPv4 and port
NOTES: This test scenario should work for all Cone NAT implementations - Full
Cone NAT, Restricted Cone NAT, and Port Restricted Cone NAT. For a discussion
of each type of Cone NAT, please see RFC 3489.
This test is only run when the testvar 'natSupportsP2P' is set to yes.
References:
IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 6: Hairpinning Behavior
https://tools.ietf.org/html/rfc4787#section-6
| Test |
Module |
Name |
Synopsis |
Verify Port-Restricted, Address-Restricted, or Full-Cone NAPT for UDP connections |
nat.tcl |
cdrouter_nat_520 |
Verify Port-Restricted, Address-Restricted, or Full-Cone NAPT for UDP connections |
step 1. Forward a UDP packet from a LAN client to the WAN
step 2. Verify packet is received
step 3. Follow the steps below based on the value of the natMode testvar:
For Full-Cone NAT
step 4. Forward a packet using a different source port but same IP address from the WAN
step 5. Verify the packet is forwarded to the LAN
step 6. Forward a packet using a different IPv4 address and same source port
step 7. Verify the packet is forwarded to the LAN
step 8. Forward a packet using the same IPv4 address and same source port
step 9. Verify the packet is forwarded to the LAN
For Address-Restricted NAT
step 4. Forward a packet using a different source port but same IP address from the WAN
step 5. Verify the packet is forwarded to the LAN
step 6. Forward a packet using a different IPv4 address and same source port
step 7. Verify the packet is not forwarded to the LAN
step 8. Forward a packet using the same IPv4 address and same source port
step 9. Verify the packet is forwarded to the LAN
For Port-Restricted NAT
step 4. Forward a packet using a different source port but same IP address from the WAN
step 5. Verify the packet is not forwarded to the LAN
step 6. Forward a packet using a different IPv4 address and same source port
step 7. Verify the packet is not forwarded to the LAN
step 8. Forward a packet using the same IPv4 address and same source port
step 9. Verify the packet is forwarded to the LAN
NOTE: Most NAPT routers use either Port-Restricted NAT, Address-Restricted NAT,
or Full-Cone NAT. By default, CDRouter assumes Port-Restricted NAT, but the type
of NAPT in use can be configured using the testvar 'natMode'.
References:
IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"
https://tools.ietf.org/html/rfc3022
| Test |
Module |
Name |
Synopsis |
Verify TCP connections using TCP window scale option through NAT |
nat.tcl |
cdrouter_nat_530 |
Verify TCP connections using TCP window scale option through NAT |
step 1. Configure a LAN client to set the TCP window scale option using value '4'
and a TCP window size of 65535
step 2. Configure a WAN server to set the TCP window scale option using value '4'
and a TCP window size of 65535
step 3. Initiate a outbound TCP connection from the LAN client to the WAN client
step 4. Verify both TCP connections received the same TCP window scale option
with the same scaling factor '4'. The TCP window scale option should
not be modified. Stop the test here if the window scale option is modified.
step 5. Send a data block from the LAN to the WAN at the start of the data sequence
step 6. Move the sequence ahead (65535 * 3) so that it would be outside of the
current window if TCP window scaling is not being applied
step 7. Send a new data block from the LAN to the WAN and verify the WAN server
can echo back the data block.
step 8. Repeat the Steps 5 and 6 until 5 data blocks have been sent
step 9. Send a data block from the WAN to the LAN using current data sequence
step 10. Move the sequence ahead (65535 * 3) so that it would be outside of the
current window if TCP window scaling is not being applied
step 11. Send a new data block from the WAN to the LAN and verify the LAN client
can echo back the data block.
step 12. Repeat the Steps 9 and 10 until 5 data blocks have been sent
step 13. Close the TCP connection
NOTE: If a firewall/NAT device is tracking the sequence number of TCP data, it
needs to understand the TCP window scale option. This test is designed to find
issues with devices that are not applying the TCP window scale factor to the
the TCP window. If a device is not maintaining any TCP sequence number state,
the TCP connection should not experience any problems.
References:
IETF RFC 1323 "TCP Extensions for High Performance"
https://tools.ietf.org/html/rfc1323
| Test |
Module |
Name |
Synopsis |
Verify TCP Fast Open cookie request through NAT |
nat.tcl |
cdrouter_nat_600 |
Verify TCP Fast Open cookie request through NAT |
step 1. Configure a LAN client to enable TCP Fast Open support
step 2. Configure WAN server to enable TCP Fast Open support
step 3. Initiate an outbound TCP connection from the LAN client to
the WAN server. Client includes a TCP Fast Open cookie
request option in its initial SYN packet.
step 4. Verify LAN client received a TCP Fast Open cookie option
in the SYN+ACK from the WAN server during the normal TCP
three-way handshake.
step 5. Verify TCP connection was established successfully.
step 6. Close the TCP connection
NOTE: TCP Fast Open does not currently have an officially assigned
IANA TCP option value. Therefore, this test uses the experimental
TCP option value 0xfe and prepends the magic value 0xf989 to each
cookie in order to distinguish TFO cookie request/TFO cookie
options from other experimental TCP options. The fact that these
are not official IANA values should not be a factor in this
NAT-style test since CDRouter is acting as both the client and
server.
References:
IETF Internet-Draft draft-ietf-tcpm-fastopen "TCP Fast Open"
https://tools.ietf.org/html/draft-ietf-tcpm-fastopen
| Test |
Module |
Name |
Synopsis |
Verify TCP connections using TCP Fast Open option through NAT |
nat.tcl |
cdrouter_nat_610 |
Verify TCP connections using TCP Fast Open option through NAT |
step 1. Configure a LAN client to enable TCP Fast Open support
step 2. Configure WAN server to enable TCP Fast Open support
step 3. Initiate an outbound TCP connection from the LAN client to
the WAN server. Client includes a TCP Fast Open cookie
request option in its initial SYN packet.
step 4. Verify LAN client received a TCP Fast Open cookie option
in the SYN+ACK from the WAN server during the normal TCP
three-way handshake.
step 5. Verify TCP connection was established successfully.
step 6. Close the TCP connection
step 7. Initiate an outbound TCP connection from the LAN client to
the WAN server, client includes data along with the TCP
Fast Open cookie from step 4 in its SYN packet.
step 8. WAN server sends its response data in an extra ACK between
the server's SYN+ACK and the client's ACK during the
normal TCP three-way handshake.
step 9. Verify TCP connection was established successfully
step 10. Verify LAN client received expected server data
step 11. Verify WAN server received expected client data
step 12. Close the TCP connection
NOTE: TCP Fast Open does not currently have an officially assigned
IANA TCP option value. Therefore, this test uses the experimental
TCP option value 0xfe and prepends the magic value 0xf989 to each
cookie in order to distinguish TFO cookie request/TFO cookie
options from other experimental TCP options. The fact that these
are not official IANA values should not be a factor in this
NAT-style test since CDRouter is acting as both the client and
server.
References:
IETF Internet-Draft draft-ietf-tcpm-fastopen "TCP Fast Open"
https://tools.ietf.org/html/draft-ietf-tcpm-fastopen
nat-timeout.tcl
NAPT tests for session timers
| Test |
Module |
Name |
Synopsis |
Verify NAT TCP session timeout after FIN close |
nat-timeout.tcl |
cdrouter_nat_timeout_1 |
Verify NAT TCP session timeout after FIN close |
step 1. Initiate an outbound TCP connection to next TCP port
step 2. Verify the connection is established
step 3. Close the TCP connection using FIN from WAN
step 4. Wait for natFinTimeout to expire
step 5. Retransmit the last TCP segment from the WAN to LAN
step 6. Verify TCP packet from the WAN is not forwarded to LAN
step 7. Initiate a second outbound TCP connection to same TCP port
step 8. Verify the connection is established
step 9. Close the TCP connection using FIN from WAN
step 10. Wait for natFinTimeout - 5 seconds
step 11. Retransmit the last TCP segment from the WAN to LAN
step 12. Verify TCP packet from the WAN is forwarded to LAN
NOTE: This test verifies that the router maintains a NAT entry for a
TCP connection that has been closed for 'natFinTimeout' seconds. The
natFinTimeout setting is configured in the configuration file
using the testvar natFinTimeout.
NOTE: There are two mains types of implementations of the natFinTimeout
timer. Some implementations delete the NAT entry after a FIN event
occurs and the natFinTimeout occurs. Other implementations reset the
timeout each time a packet is seen. This test case uses 2 TCP sessions
to verify the behavior since sending TCP data to verify the timeout can
cause some implementations to reset the timeout.
NOTE: If the CPE is not designed to immediately delete expired NAT
mappings, the 'natLagTime' testvar should be set to force CDRouter to
wait a fixed number of seconds before verifying that the mapping has
been deleted.
References:
IETF RFC 2663 "NAT Terminology and Considerations" Section 2.6: End of session for TCP, UDP and others
https://tools.ietf.org/html/rfc2663#section-2.6
| Test |
Module |
Name |
Synopsis |
Verify NAT TCP session timeout after RST close |
nat-timeout.tcl |
cdrouter_nat_timeout_2 |
Verify NAT TCP session timeout after RST close |
step 1. Initiate an outbound TCP connection to next TCP port
step 2. Verify the connection is established
step 3. Close the TCP connection using RST from LAN
step 4. Wait for natRstTimeout to expire
step 5. Retransmit the last TCP segment from the WAN to LAN
step 6. Verify TCP packet from the WAN is not forwarded to LAN
step 7. Initiate a second outbound TCP connection to same TCP port
step 8. Verify the connection is established
step 9. Close the TCP connection using RST from LAN
step 10. Wait for natRstTimeout - 5 seconds
step 11. Retransmit the last TCP segment from the WAN to LAN
step 12. Verify TCP packet from the WAN is forwarded to LAN
NOTE: This test verifies that the router maintains a NAT entry for a
TCP connection that has been closed for 'natRstTimeout' seconds. The
natRstTimeout setting is configured in the configuration file
using the testvar natRstTimeout.
NOTE: There are two mains types of implementations of the natRstTimeout
timer. Some implementations delete the NAT entry after an RST event
occurs and the natRstTimeout occurs. Other implementations reset the
timeout each time a packet is seen. This test case uses 2 TCP sessions
to verify the behavior since sending TCP data to verify the timeout can
cause some implementations to reset the timeout.
NOTE: If the CPE is not designed to immediately delete expired NAT
mappings, the 'natLagTime' testvar should be set to force CDRouter to
wait a fixed number of seconds before verifying that the mapping has
been deleted.
References:
IETF RFC 2663 "NAT Terminology and Considerations" Section 2.6: End of session for TCP, UDP and others
https://tools.ietf.org/html/rfc2663#section-2.6
| Test |
Module |
Name |
Synopsis |
Verify NAT TCP session timeout for established session |
nat-timeout.tcl |
cdrouter_nat_timeout_10 |
Verify NAT TCP session timeout for established session |
step 1. Initiate an outbound TCP connection to next TCP port
step 2. Verify the connection is established
step 3. Wait for natTcpTimeout to expire
step 4. Retransmit the last TCP segment from the WAN to LAN
step 5. Verify TCP packet from the WAN is not forwarded to LAN
step 6. Initiate a second outbound TCP connection to same TCP port
step 7. Verify the connection is established
step 8. Wait for natTcpTimeout - 5 seconds
step 9. Retransmit the last TCP segment from the WAN to LAN
step 10. Verify TCP packet from the WAN is forwarded to LAN
NOTE: This test verifies that the router deletes the NAT entry
for a TCP session that has been inactive for 'natTcpTimeout'
seconds. The natTcpTimeout can be configured using the testvar
natTcpTimeout.
NOTE: The default natTcpTimeout on most NAT devices can be quite long.
Some devices default to 24 hours (86400). This test can be quite
time consuming with long timeout values.
NOTE: If the CPE is not designed to immediately delete expired NAT
mappings, the 'natLagTime' testvar should be set to force CDRouter to
wait a fixed number of seconds before verifying that the mapping has
been deleted.
References:
IETF RFC 2663 "NAT Terminology and Considerations" Section 2.6: End of session for TCP, UDP and others
https://tools.ietf.org/html/rfc2663#section-2.6
| Test |
Module |
Name |
Synopsis |
Verify NAT TCP SYN session timeout |
nat-timeout.tcl |
cdrouter_nat_timeout_11 |
Verify NAT TCP SYN session timeout |
step 1. Send outbound TCP SYN to next TCP port
step 2. Wait for natSynTimeout to expire
step 3. Send TCP SYN-ACK from WAN back to LAN host
step 4. Verify TCP packet from the WAN is not forwarded to LAN
step 5. Send a second outbound TCP SYN to same TCP port
step 6. Wait for natSynTimeout - 5 seconds
step 7. Send TCP SYN-ACK from WAN back to LAN host
step 8. Verify TCP packet from the WAN is forwarded to LAN
NOTE: This test verifies that the router maintains a NAT entry for a
partially open TCP connection for 'natSynTimeout' seconds. The
natSynTimeout setting is configured in the configuration file
using the testvar natSynTimeout.
NOTE: If the CPE is not designed to immediately delete expired NAT
mappings, the 'natLagTime' testvar should be set to force CDRouter to
wait a fixed number of seconds before verifying that the mapping has
been deleted.
References:
IETF RFC 2663 "NAT Terminology and Considerations" Section 2.6: End of session for TCP, UDP and others
https://tools.ietf.org/html/rfc2663#section-2.6
| Test |
Module |
Name |
Synopsis |
Verify NAT UDP session timeout |
nat-timeout.tcl |
cdrouter_nat_timeout_20 |
Verify NAT UDP session timeout |
step 1. Initiate an outbound UDP Echo
step 2. Verify the UDP packet is received on the WAN
step 3. Wait for natUdpTimeout seconds
step 4. Transmit the UDP response from the WAN to LAN
step 5. Verify UDP packet from the WAN is not forwarded to LAN
step 6. Initiate a second outbound UDP Echo
step 7. Verify the packet is received on the WAN
step 8. Wait for natUdpTimeout - 5 seconds
step 9. Transmit the UDP response from the WAN to LAN
step 10. Verify UDP packet from the WAN is forwarded to LAN
NOTE: This test verifies that the router maintains a NAT entry for a
UDP connections for 'natUdpTimeout' seconds. The natUdpTimeout
setting is configured in the configuration file using the testvar
natUdpTimeout.
NOTE: If the CPE is not designed to immediately delete expired NAT
mappings, the 'natLagTime' testvar should be set to force CDRouter to
wait a fixed number of seconds before verifying that the mapping has
been deleted.
References:
IETF RFC 2663 "NAT Terminology and Considerations" Section 2.6: End of session for TCP, UDP and others
https://tools.ietf.org/html/rfc2663#section-2.6
| Test |
Module |
Name |
Synopsis |
Verify NAT DNS session timeout |
nat-timeout.tcl |
cdrouter_nat_timeout_25 |
Verify NAT DNS session timeout |
step 1. Initiate an outbound DNS query
step 2. Verify the DNS packet is received on the WAN
step 3. Wait for natDnsTimeout seconds
step 4. Transmit the DNS response from the WAN to LAN
step 5. Verify DNS packet from the WAN is not forwarded to LAN
step 6. Initiate a second outbound DNS query
step 7. Verify the packet is received on the WAN
step 8. Wait for natDnsTimeout - 5 seconds
step 9. Transmit the DNS response from the WAN to LAN
step 10. Verify DNS packet from the WAN is forwarded to LAN
NOTE: This test verifies that the router maintains a NAT entry for
a DNS connection for 'natDnsTimeout' seconds. The natDnsTimeout
setting is configured in the configuration file using the testvar
natDnsTimeout. If the implementation does not make any
distintiction between DNS and generic UDP, this timeout should be
set to the same value as the natUdpTimeout.
NOTE: If the CPE is not designed to immediately delete expired NAT
mappings, the 'natLagTime' testvar should be set to force CDRouter to
wait a fixed number of seconds before verifying that the mapping has
been deleted.
References:
IETF RFC 2663 "NAT Terminology and Considerations" Section 2.6: End of session for TCP, UDP and others
https://tools.ietf.org/html/rfc2663#section-2.6
| Test |
Module |
Name |
Synopsis |
Verify NAT ICMP session timeout |
nat-timeout.tcl |
cdrouter_nat_timeout_30 |
Verify NAT ICMP session timeout |
step 1. Initiate an outbound ICMP Echo Request
step 2. Verify the packet is received on the WAN
step 3. Wait for natIcmpTimeout seconds
step 4. Transmit the Echo Reply from the WAN to LAN
step 5. Verify ICMP packet from the WAN is not forwarded to LAN
step 6. Initiate a second outbound ICMP Echo Request
step 7. Verify the packet is received on the WAN
step 8. Wait for natIcmpTimeout - 5 seconds
step 9. Transmit the Echo Reply from the WAN to LAN
step 10. Verify ICMP packet from the WAN is forwarded to LAN
NOTE: This test verifies that the router maintains a NAT entry for a
ICMP connections for 'natIcmpTimeout' seconds. The
natIcmpTimeout setting is configured in the configuration file
using the testvar natIcmpTimeout.
NOTE: If the CPE is not designed to immediately delete expired NAT
mappings, the 'natLagTime' testvar should be set to force CDRouter to
wait a fixed number of seconds before verifying that the mapping has
been deleted.
References:
IETF RFC 2663 "NAT Terminology and Considerations" Section 2.6: End of session for TCP, UDP and others
https://tools.ietf.org/html/rfc2663#section-2.6
| Test |
Module |
Name |
Synopsis |
Verify RTSP session timeout for established session |
nat-timeout.tcl |
cdrouter_nat_timeout_40 |
Verify RTSP session timeout for established session |
step 1. Initiate an outbound RTSP connection
step 2. Verify the connection is established
step 3. Wait for natRtspTimeout to expire
step 4. Verify RTP and RTCP packets from the WAN are not forwarded to LAN
step 5. Initiate a second outbound RTSP connection
step 6. Verify the connection is established
step 7. Wait for natRtspTimeout - 5 seconds
step 8. Verify RTP and RTCP packets from the WAN are forwarded to LAN
NOTE: This test verifies that the router deletes the RTSP entry
for a RTSP session that has been inactive for 'natRtspTimeout'
seconds. The natRtspTimeout can be configured using the testvar
natRtspTimeout.
NOTE: If the CPE is not designed to immediately delete expired NAT
mappings, the 'natLagTime' testvar should be set to force CDRouter to
wait a fixed number of seconds before verifying that the mapping has
been deleted.
nat-frag.tcl
NAPT tests for IPv4 fragmentation
| Test |
Module |
Name |
Synopsis |
Verify NAT with TCP IPv4 fragments |
nat-frag.tcl |
nat_frag_1 |
Verify NAT with TCP IPv4 fragments |
step 1. Initiate an outbound TCP connection
step 2. Set outgoing MTU to 108 bytes to force fragmentation
step 3. Send a fragmented TCP data segment
step 4. Verify the TCP data is received on WAN side
step 5. Send a return response back to LAN
step 6. Verify return packet is received on the LAN
step 7. Repeat for multiple packet sizes
References:
IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"
https://tools.ietf.org/html/rfc3022
IETF Internet-Draft draft-ietf-intarea-frag-fragile-02 "Real Time Streaming Protocol (RTSP)" Section 4.2: Network Address Translation (NAT)
IP fragmentation causes problems for Network Address Translation (NAT) devices. When a NAT
device detects a new, outbound flow, it maps that flow's source port and IP address to another
source port and IP address. Having created that mapping, the NAT device translates:
* The Source IP Address and Source Port on each outbound packet.
* The Destination IP Address and Destination Port on each inbound packet.
A+P and Carrier Grade NAT (CGN) are two common NAT strategies. In both approaches the NAT
device must virtually reassemble fragmented packets in order to translate and forward each
fragment.
Virtual reassembly in the network is problematic, because it is computationally expensive and
because it is prone to attacks.
https://tools.ietf.org/id/draft-ietf-intarea-frag-fragile-02.html#section-4.2
| Test |
Module |
Name |
Synopsis |
Verify NAT with TCP IPv4 out-of-order fragments |
nat-frag.tcl |
nat_frag_2 |
Verify NAT with TCP IPv4 out-of-order fragments |
step 1. Initiate an outbound TCP connection
step 2. Set outgoing MTU to 108 bytes to force fragmentation
step 3. Send a fragmented TCP data segment with fragments in reverse order
step 4. Verify the TCP data is received on WAN side
step 5. Send a return response back to LAN
step 6. Verify return packet is received on the LAN
step 7. Repeat for multiple packet sizes
References:
IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"
https://tools.ietf.org/html/rfc3022
IETF Internet-Draft draft-ietf-intarea-frag-fragile-02 "Real Time Streaming Protocol (RTSP)" Section 4.2: Network Address Translation (NAT)
IP fragmentation causes problems for Network Address Translation (NAT) devices. When a NAT
device detects a new, outbound flow, it maps that flow's source port and IP address to another
source port and IP address. Having created that mapping, the NAT device translates:
* The Source IP Address and Source Port on each outbound packet.
* The Destination IP Address and Destination Port on each inbound packet.
A+P and Carrier Grade NAT (CGN) are two common NAT strategies. In both approaches the NAT
device must virtually reassemble fragmented packets in order to translate and forward each
fragment.
Virtual reassembly in the network is problematic, because it is computationally expensive and
because it is prone to attacks.
https://tools.ietf.org/id/draft-ietf-intarea-frag-fragile-02.html#section-4.2
| Test |
Module |
Name |
Synopsis |
Verify NAT with UDP IPv4 fragments |
nat-frag.tcl |
nat_frag_11 |
Verify NAT with UDP IPv4 fragments |
step 1. Initiate an outbound UDP connection (UDP Echo) with large fragmented packet
step 2. Verify the udp is received on WAN side
step 3. Send a return response back to LAN
step 4. Verify return packet is received on the LAN
step 5. Repeat for multiple packet sizes
References:
IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"
https://tools.ietf.org/html/rfc3022
IETF Internet-Draft draft-ietf-intarea-frag-fragile-02 "Real Time Streaming Protocol (RTSP)" Section 4.2: Network Address Translation (NAT)
IP fragmentation causes problems for Network Address Translation (NAT) devices. When a NAT
device detects a new, outbound flow, it maps that flow's source port and IP address to another
source port and IP address. Having created that mapping, the NAT device translates:
* The Source IP Address and Source Port on each outbound packet.
* The Destination IP Address and Destination Port on each inbound packet.
A+P and Carrier Grade NAT (CGN) are two common NAT strategies. In both approaches the NAT
device must virtually reassemble fragmented packets in order to translate and forward each
fragment.
Virtual reassembly in the network is problematic, because it is computationally expensive and
because it is prone to attacks.
https://tools.ietf.org/id/draft-ietf-intarea-frag-fragile-02.html#section-4.2
| Test |
Module |
Name |
Synopsis |
Verify NAT with UDP IPv4 out-of-order fragments |
nat-frag.tcl |
nat_frag_12 |
Verify NAT with UDP IPv4 out-of-order fragments |
step 1. Initiate an outbound UDP connection (UDP Echo) with large fragmented packet
step 2. Send fragments in reverse order
step 3. Verify the udp is received on WAN side
step 4. Send a return response back to LAN
step 5. Verify return packet is received on the LAN
step 6. Repeat for multiple packet sizes
References:
IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"
https://tools.ietf.org/html/rfc3022
IETF Internet-Draft draft-ietf-intarea-frag-fragile-02 "Real Time Streaming Protocol (RTSP)" Section 4.2: Network Address Translation (NAT)
IP fragmentation causes problems for Network Address Translation (NAT) devices. When a NAT
device detects a new, outbound flow, it maps that flow's source port and IP address to another
source port and IP address. Having created that mapping, the NAT device translates:
* The Source IP Address and Source Port on each outbound packet.
* The Destination IP Address and Destination Port on each inbound packet.
A+P and Carrier Grade NAT (CGN) are two common NAT strategies. In both approaches the NAT
device must virtually reassemble fragmented packets in order to translate and forward each
fragment.
Virtual reassembly in the network is problematic, because it is computationally expensive and
because it is prone to attacks.
https://tools.ietf.org/id/draft-ietf-intarea-frag-fragile-02.html#section-4.2
| Test |
Module |
Name |
Synopsis |
Verify NAT with ICMP IPv4 fragments |
nat-frag.tcl |
nat_frag_21 |
Verify NAT with ICMP IPv4 fragments |
step 1. Initiate an outbound ICMP request with large fragmented packet
step 2. Verify the udp is received on WAN side
step 3. Send a return response back to LAN
step 4. Verify return packet is received on the LAN
step 5. Repeat for multiple packet sizes
References:
IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"
https://tools.ietf.org/html/rfc3022
IETF Internet-Draft draft-ietf-intarea-frag-fragile-02 "Real Time Streaming Protocol (RTSP)" Section 4.2: Network Address Translation (NAT)
IP fragmentation causes problems for Network Address Translation (NAT) devices. When a NAT
device detects a new, outbound flow, it maps that flow's source port and IP address to another
source port and IP address. Having created that mapping, the NAT device translates:
* The Source IP Address and Source Port on each outbound packet.
* The Destination IP Address and Destination Port on each inbound packet.
A+P and Carrier Grade NAT (CGN) are two common NAT strategies. In both approaches the NAT
device must virtually reassemble fragmented packets in order to translate and forward each
fragment.
Virtual reassembly in the network is problematic, because it is computationally expensive and
because it is prone to attacks.
https://tools.ietf.org/id/draft-ietf-intarea-frag-fragile-02.html#section-4.2
| Test |
Module |
Name |
Synopsis |
Verify NAT with ICMP IPv4 out-of-order fragments |
nat-frag.tcl |
nat_frag_22 |
Verify NAT with ICMP IPv4 out-of-order fragments |
step 1. Initiate an outbound ICMP request with large fragmented packet
step 2. Send fragments in reverse order
step 3. Verify the ICMP is received on WAN side
step 4. Send a return response back to LAN
step 5. Verify return packet is received on the LAN
step 6. Repeat for multiple packet sizes
References:
IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"
https://tools.ietf.org/html/rfc3022
IETF Internet-Draft draft-ietf-intarea-frag-fragile-02 "Real Time Streaming Protocol (RTSP)" Section 4.2: Network Address Translation (NAT)
IP fragmentation causes problems for Network Address Translation (NAT) devices. When a NAT
device detects a new, outbound flow, it maps that flow's source port and IP address to another
source port and IP address. Having created that mapping, the NAT device translates:
* The Source IP Address and Source Port on each outbound packet.
* The Destination IP Address and Destination Port on each inbound packet.
A+P and Carrier Grade NAT (CGN) are two common NAT strategies. In both approaches the NAT
device must virtually reassemble fragmented packets in order to translate and forward each
fragment.
Virtual reassembly in the network is problematic, because it is computationally expensive and
because it is prone to attacks.
https://tools.ietf.org/id/draft-ietf-intarea-frag-fragile-02.html#section-4.2
renum-dhcp.tcl
WAN side renumbering tests with DHCP on the WAN
| Test |
Module |
Name |
Synopsis |
Verify WAN client learns new IP address when WAN server renumbers |
renum-dhcp.tcl |
cdrouter_renumber_1 |
Verify WAN client learns new IP address when WAN server renumbers |
step 1. Change the wanIspAssignIp address to a new address
step 2. Wait for DHCP lease to expire on WAN interface
step 3. Verify WAN client sends DHCPREQUEST for same IP address
step 4. Send DHCPNAK for that address
step 5. Verify DHCP WAN client restarts DHCPDISCOVERY and learns new IP
step 6. Verify new address responds to ping from LAN
step 7. Verify the old address no longer responds to ping from LAN
step 8. Verify new address responds to ARP request from WAN
step 9. Verify LAN client can ping remote host using new address
step 10. Restore original IP address
step 11. Verify LAN client can ping remote host
NOTE: Step 8 will be skipped if testvar IPv4HopCount > 1 or testvar
wanIspAssignGateway is defined as this indicates that the WAN client and
WAN server are not on the same subnet.
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol"
https://tools.ietf.org/html/rfc2131
| Test |
Module |
Name |
Synopsis |
Verify existing TCP connections can be reestablished after WAN renumber |
renum-dhcp.tcl |
cdrouter_renumber_2 |
Verify existing TCP connections can be reestablished after WAN renumber |
step 1. Initiate TCP connection from LAN to WAN
step 2. Change the wanIspAssignIp address to a new address
step 3. Wait for DHCP lease to expire on WAN interface
step 4. Verify WAN client sends DHCPREQUEST for same IP address
step 5. Send DHCPNAK for that address
step 6. Verify DHCP WAN client restarts DHCPDISCOVERY and learns new IP
step 7. Verify new address responds to ping from LAN
step 8. Verify the old address no longer responds to ping from LAN
step 9. Initiate same TCP connection from LAN to WAN
step 10. Verify TCP connection works
step 11. Reset wanIspAssignIp to its original value and wait for a DHCP renew
step 12. Verify the remoteHost responds to ping from the LAN
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol"
https://tools.ietf.org/html/rfc2131
| Test |
Module |
Name |
Synopsis |
Verify LAN clients learn new DNS server during LAN side renew |
renum-dhcp.tcl |
cdrouter_renumber_3 |
Verify LAN clients learn new DNS server during LAN side renew |
step 1. Change the DNS server address
step 2. Wait for WAN client to renew lease and learn new DNS Server
step 3. Initiate LAN client renew
step 4. Verify LAN client receives new DNS server address
step 5. Reset the WAN client's DNS server address
step 6. Verify the LAN client can ping a remote host
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol"
https://tools.ietf.org/html/rfc2131
| Test |
Module |
Name |
Synopsis |
Verify LAN clients learn new longer domain name during LAN side renew |
renum-dhcp.tcl |
cdrouter_renumber_4 |
Verify LAN clients learn new longer domain name during LAN side renew |
step 1. Change the DNS domain name to a longer domain name
step 2. Wait for WAN client to renew lease and learn new domain name
step 3. Initiate LAN client renew
step 4. Verify LAN client receives new domain name
step 5. Reset the WAN client's DNS domain name
step 6. Verify the LAN client can ping a remote host
This test checks that the router correctly handles changes to the domain
when it is modified. QACafe has seen cases where domain names passed on to
DHCP clients were corrupted when changed after the WAN side renewed its DHCP
lease.
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol"
https://tools.ietf.org/html/rfc2131
| Test |
Module |
Name |
Synopsis |
Verify LAN clients learn new shorter domain name during LAN side renew |
renum-dhcp.tcl |
cdrouter_renumber_5 |
Verify LAN clients learn new shorter domain name during LAN side renew |
step 1. Change the DNS domain name to a shorter name
step 2. Wait for WAN client to renew lease and learn new domain name
step 3. Initiate LAN client renew
step 4. Verify LAN client receives new domain name
step 5. Reset the WAN client's DNS domain name
step 6. Verify the LAN client can ping a remote host
This test checks that the router correctly handles changes to the domain
when it is modified. QACafe has seen cases where domain names passed on to
DHCP clients were corrupted when changed after the WAN side renewed its DHCP
lease.
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol"
https://tools.ietf.org/html/rfc2131
| Test |
Module |
Name |
Synopsis |
Verify WAN side switches to new gateway after renumber |
renum-dhcp.tcl |
cdrouter_renumber_6 |
Verify WAN side switches to new gateway after renumber |
step 1. Change the default gateway that the DHCP server will assign
to a new IPv4 address based on testvar wanIspNextIp
step 2. Wait for DHCP lease to expire on WAN interface
step 3. Verify WAN client sends DHCPREQUEST for same IP address
step 4. Send DHCPACK that contains the new IP gateway
step 5. Wait 5 seconds for CPE to update the default gateway
step 6. Initiate TCP connection from LAN to WAN
step 7. Verify TCP connection works using the new gateway
step 8. Reset the WAN client's default gateway
step 9. Verify the LAN client can ping a remote host
NOTE: By default, this test case will wait 5 seconds after the DHCP client
has updated before checking that the new gateway is working. This time
interval can be adjusted using the testvar dhcpGatewayCache.
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol"
https://tools.ietf.org/html/rfc2131
| Test |
Module |
Name |
Synopsis |
Verify LAN clients learn additional DNS servers |
renum-dhcp.tcl |
cdrouter_renumber_50 |
Verify LAN clients learn additional DNS servers |
step 1. Add two more DNS servers to WAN side DHCP server
step 2. Wait for WAN client to renew lease and learn new DNS servers
step 3. Initiate LAN client renew
step 4. Verify LAN client receives two new DNS servers
NOTE: The router under test must support at least three DNS servers in order
to pass this test. Some routers will only include one or two DNS servers in
the DHCP DNS option offered to DHCP clients.
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol"
https://tools.ietf.org/html/rfc2131
renum-pppoe.tcl
WAN side renumbering tests with PPPoE on the WAN
| Test |
Module |
Name |
Synopsis |
Verify WAN PPPoE client learns new IP address when WAN server renumbers |
renum-pppoe.tcl |
cdrouter_renum_pppoe_1 |
Verify WAN PPPoE client learns new IP address when WAN server renumbers |
step 1. Change the wanIspAssignIp address to a new address
step 2. Terminate the current PPPoE session with the client
step 3. Verify WAN attempts to establish new PPPoE session
step 4. Verify LAN client can ping remote host using new address
step 5. Reset the WAN configuration to original IP address
step 6. Verify the original PPPoE session has been reestablished
NOTE: The amount of time the test waits to recover the PPP based
link can be configured by adjusting the testvar pppRestartTimeout.
This variable contains the number of milliseconds to wait for
PPP based protocols to recover. The default is 300000 (300 seconds).
References:
IETF RFC 2516 "A Method for Transmitting PPP Over Ethernet (PPPoE)"
https://tools.ietf.org/html/rfc2516
| Test |
Module |
Name |
Synopsis |
Verify existing TCP connections can be reestablished after WAN renumber |
renum-pppoe.tcl |
cdrouter_renum_pppoe_2 |
Verify existing TCP connections can be reestablished after WAN renumber |
step 1. Initiate TCP connection from LAN to WAN
step 2. Change the wanIspAssignIp address to a new address
step 3. Terminate the current PPPoE session with the client
step 4. Verify WAN attempts to establish new PPPoE session
step 5. Initiate same TCP connection from LAN to WAN
step 6. Verify TCP connection works
step 7. Reset the WAN configuration to original IP address
step 8. Verify the original PPPoE session has been reestablished
NOTE: The amount of time the test waits to recover the PPP based
link can be configured by adjusting the testvar pppRestartTimeout.
This variable contains the number of milliseconds to wait for
PPP based protocols to recover. The default is 300000 (300 seconds).
References:
IETF RFC 2516 "A Method for Transmitting PPP Over Ethernet (PPPoE)"
https://tools.ietf.org/html/rfc2516
| Test |
Module |
Name |
Synopsis |
Verify LAN clients learn new DNS server during LAN side renew |
renum-pppoe.tcl |
cdrouter_renum_pppoe_3 |
Verify LAN clients learn new DNS server during LAN side renew |
step 1. Change the DNS server address
step 2. Terminate PPPoE session
step 3. Verify PPPoE client starts new session
step 4. Initiate LAN client renew
step 5. Verify LAN client receives new DNS server address
step 6. Reset the WAN configuration
step 7. Verify the original PPPoE session has been reestablished
References:
IETF RFC 2516 "A Method for Transmitting PPP Over Ethernet (PPPoE)"
https://tools.ietf.org/html/rfc2516
| Test |
Module |
Name |
Synopsis |
Verify WAN side switches to new gateway after renumber |
renum-pppoe.tcl |
cdrouter_renum_pppoe_6 |
Verify WAN side switches to new gateway after renumber |
step 1. Change the wanIspIp address to a new IP address
step 2. Terminate PPPoE session on WAN interface
step 3. Verify PPPoE client starts new session
step 4. Initiate same TCP connection from LAN to WAN
step 5. Verify TCP connection works
step 6. Close TCP connection
step 7. Change the wanIspIp to the original IP address
step 8. Reset the WAN interface
step 9. Verify the original PPPoE session has been reestablished
References:
IETF RFC 2516 "A Method for Transmitting PPP Over Ethernet (PPPoE)"
https://tools.ietf.org/html/rfc2516
| Test |
Module |
Name |
Synopsis |
Verify LAN clients learn additional DNS server |
renum-pppoe.tcl |
cdrouter_renum_pppoe_50 |
Verify LAN clients learn additional DNS server |
step 1. Change secondary DNS servers on WAN side
step 2. Terminate existing PPPoE session
step 3. Verify PPPoE client starts new PPPoE session
step 3. Initiate LAN client renew
step 4. Verify LAN client receives new DNS server
step 9. Reset the WAN configuration to original IP address
step 10. Verify the original PPPoE session has been reestablished
NOTE: The router under test must support at least two DNS servers in order
to pass this test.
References:
IETF RFC 2516 "A Method for Transmitting PPP Over Ethernet (PPPoE)"
https://tools.ietf.org/html/rfc2516
renum-pptp.tcl
WAN side renumbering tests with PPTP on the WAN
| Test |
Module |
Name |
Synopsis |
Verify WAN PPTP client learns new IP address when WAN server renumbers |
renum-pptp.tcl |
cdrouter_renum_pptp_1 |
Verify WAN PPTP client learns new IP address when WAN server renumbers |
step 1. Change the wanIspAssignIp address to a new address
step 2. Terminate the current PPP session with the client
step 3. Verify WAN attempts to establish new PPP session
step 4. Verify LAN client can ping remote host using new address
step 5. Resetting the WAN configuration to original IP address
step 6. Verify the original PPPTP session has been reestablished
NOTE: The amount of time the test waits to recover the PPP based
link can be configured by adjusting the testvar 'pppRestartTimeout'.
This variable contains the number of milliseconds to wait for
PPP based protocols to recover. The default is 300000 (300 seconds).
References:
IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)"
https://tools.ietf.org/html/rfc2637
| Test |
Module |
Name |
Synopsis |
Verify existing TCP connections can be reestablished after WAN renumber |
renum-pptp.tcl |
cdrouter_renum_pptp_2 |
Verify existing TCP connections can be reestablished after WAN renumber |
step 1. Initiate TCP connection from LAN to WAN
step 2. Change the wanIspAssignIp address to a new address
step 3. Terminate the current PPP session with the client
step 4. Verify WAN attempts to establish new PPP session
step 5. Initiate same TCP connection from LAN to WAN
step 6. Verify TCP connection works
step 7. Resetting the WAN configuration to original IP address
step 8. Verify the original PPPTP session has been reestablished
NOTE: The amount of time the test waits to recover the PPP based
link can be configured by adjusting the testvar 'pppRestartTimeout'.
This variable contains the number of milliseconds to wait for
PPP based protocols to recover. The default is 300000 (300 seconds).
References:
IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)"
https://tools.ietf.org/html/rfc2637
| Test |
Module |
Name |
Synopsis |
Verify LAN clients learn new DNS server during LAN side renew |
renum-pptp.tcl |
cdrouter_renum_pptp_3 |
Verify LAN clients learn new DNS server during LAN side renew |
step 1. Change the DNS server address
step 2. Terminate PPP session
step 3. Verify PPP client starts new session
step 4. Initiate LAN client renew
step 5. Verify LAN client receives new DNS server address
step 6. Resetting the WAN configuration to original IP address
step 7. Verify the original PPPTP session has been reestablished
References:
IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)"
https://tools.ietf.org/html/rfc2637
| Test |
Module |
Name |
Synopsis |
Verify WAN side switches to new gateway after renumber |
renum-pptp.tcl |
cdrouter_renum_pptp_6 |
Verify WAN side switches to new gateway after renumber |
step 1. Initiate TCP connection from LAN to WAN
step 2. Change the wanIspAssignIp address to a new address
step 3. Terminate PPP session on WAN interface
step 4. Verify PPP client starts new session
step 5. Initiate same TCP connection from LAN to WAN
step 6. Verify TCP connection works
step 7. Resetting the WAN configuration to original IP address
step 8. Verify the original PPPTP session has been reestablished
References:
IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)"
https://tools.ietf.org/html/rfc2637
| Test |
Module |
Name |
Synopsis |
Verify LAN clients learn additional DNS server |
renum-pptp.tcl |
cdrouter_renum_pptp_50 |
Verify LAN clients learn additional DNS server |
step 1. Change secondary DNS servers on WAN side
step 2. Terminate existing PPP session
step 3. Verify PPP client starts new PPP session
step 3. Initiate LAN client renew
step 4. Verify LAN client receives new DNS server
step 5. Resetting the WAN configuration
step 6. Verify the original PPPTP session has been reestablished
NOTE: The router under test must support at least two DNS servers in order
to pass this test.
References:
IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)"
https://tools.ietf.org/html/rfc2637
renum-l2tp.tcl
WAN side renumbering tests with L2TP on the WAN
| Test |
Module |
Name |
Synopsis |
Verify WAN L2TP client learns new IP address when WAN server renumbers |
renum-l2tp.tcl |
cdrouter_renum_l2tp_1 |
Verify WAN L2TP client learns new IP address when WAN server renumbers |
step 1. Change the WanIspAssignIp address to a new address
step 2. Terminate the current PPP session with the client
step 3. Verify WAN attempts to establish new PPP session
step 4. Verify LAN client can ping remote host using new address
step 5. Reset the WAN configuration back to original IP address
step 6. Verify the original PPP session has been reestablished
NOTE: The amount of time the test waits to recover the PPP based
link can be configured by adjusting the testvar 'pppRestartTimeout'.
This variable contains the number of milliseconds to wait for
PPP based protocols to recover. The default is 300000 (300 seconds).
References:
IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""
https://tools.ietf.org/html/rfc2661
| Test |
Module |
Name |
Synopsis |
Verify existing TCP connections can be reestablished after WAN renumber |
renum-l2tp.tcl |
cdrouter_renum_l2tp_2 |
Verify existing TCP connections can be reestablished after WAN renumber |
step 1. Initiate TCP connection from LAN to WAN
step 2. Change the wanIspAssignIp address to a new address
step 3. Terminate the current PPP session with the client
step 4. Verify WAN attempts to establish new PPP session
step 5. Initiate same TCP connection from LAN to WAN
step 6. Verify TCP connection works
step 7. Reset the WAN configuration back to original IP address
step 8. Verify the original PPP session has been reestablished
NOTE: The amount of time the test waits to recover the PPP based
link can be configured by adjusting the testvar 'pppRestartTimeout'.
This variable contains the number of milliseconds to wait for
PPP based protocols to recover. The default is 300000 (300 seconds).
References:
IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""
https://tools.ietf.org/html/rfc2661
| Test |
Module |
Name |
Synopsis |
Verify LAN clients learn new DNS server during LAN side renew |
renum-l2tp.tcl |
cdrouter_renum_l2tp_3 |
Verify LAN clients learn new DNS server during LAN side renew |
step 1. Change the DNS server address
step 2. Terminate PPP session
step 3. Verify PPP client starts new session
step 4. Initiate LAN client renew
step 5. Verify LAN client receives new DNS server address
step 6. Reset the WAN configuration
step 7. Verify the original PPP session has been reestablished
References:
IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""
https://tools.ietf.org/html/rfc2661
| Test |
Module |
Name |
Synopsis |
Verify WAN side switches to new gateway after renumber |
renum-l2tp.tcl |
cdrouter_renum_l2tp_6 |
Verify WAN side switches to new gateway after renumber |
step 1. Initiate TCP connection from LAN to WAN
step 2. Change the wanIspAssignIp address to a new address
step 3. Terminate PPP session on WAN interface
step 4. Verify PPP client starts new session
step 5. Initiate same TCP connection from LAN to WAN
step 6. Verify TCP connection works
step 7. Reset the WAN configuration back to original IP address
step 8. Verify the original PPP session has been reestablished
References:
IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""
https://tools.ietf.org/html/rfc2661
| Test |
Module |
Name |
Synopsis |
Verify LAN clients learn additional DNS server |
renum-l2tp.tcl |
cdrouter_renum_l2tp_50 |
Verify LAN clients learn additional DNS server |
step 1. Change secondary DNS servers on WAN side
step 2. Terminate existing PPP session
step 3. Verify PPP client starts new PPP session
step 3. Initiate LAN client renew
step 4. Verify LAN client receives new DNS server
step 5. Reset the WAN configuration back to original IP address
step 6. Verify the original PPP session has been reestablished
NOTE: The cable/dsl router must support at least 2 DNS servers inorder
to pass this test.
References:
IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""
https://tools.ietf.org/html/rfc2661
icmp.tcl
ICMP tests for generating various ICMP packets and NAPT of ICMP data
| Test |
Module |
Name |
Synopsis |
Verify ICMP Echo Requests (ping) work through router |
icmp.tcl |
cdrouter_icmp_1 |
Verify ICMP Echo Requests (ping) work through router |
step 1. Initiate an outbound ICMP Echo Request (ping) to a WAN destination
step 2. Verify ICMP Echo Reply (ping response) is received
| Test |
Module |
Name |
Synopsis |
Verify ICMP Echo Requests from multiple LAN clients work through router |
icmp.tcl |
cdrouter_icmp_2 |
Verify ICMP Echo Requests from multiple LAN clients work through router |
step 1. Configure additional lan host
step 2. Initiate an outbound ICMP Echo Request to a WAN destination from host 1
step 3. Verify ICMP Echo Reply is received
step 4. Initiate an outbound ICMP Echo Request to a WAN destination from host 2
step 5. Verify ICMP Echo Reply is received
| Test |
Module |
Name |
Synopsis |
Verify ICMP Echo Requests to router's LAN side IP address from the LAN |
icmp.tcl |
cdrouter_icmp_5 |
Verify ICMP Echo Requests to router’s LAN side IP address from the LAN |
step 1. Initiate an outbound ICMP Echo Request to the router's LAN side IP address
step 2. Verify ICMP Echo Reply is received
| Test |
Module |
Name |
Synopsis |
Verify ICMP Echo Requests to router's WAN side IP address from the LAN |
icmp.tcl |
cdrouter_icmp_6 |
Verify ICMP Echo Requests to router’s WAN side IP address from the LAN |
step 1. Initiate an outbound ICMP Echo Request to the router's WAN side IP address
step 2. Verify ICMP Echo Reply is received
| Test |
Module |
Name |
Synopsis |
Verify ICMP Echo Requests to router's WAN side IP address from the WAN |
icmp.tcl |
cdrouter_icmp_7 |
Verify ICMP Echo Requests to router’s WAN side IP address from the WAN |
step 1. Initiate an outbound ICMP Echo Request to the router's WAN side IP
address from the WAN
step 2. Verify ICMP Echo Reply is received
Note: the testvar wanPingRespond is used to determine if pinging the
WAN-side of the DUT is expected to work or not. It defaults to "no" which
signifies that the device will not respond to pings on its WAN interface.
| Test |
Module |
Name |
Synopsis |
Verify ICMP Time Exceeded packet is sent when incoming UDP TTL is 1 |
icmp.tcl |
cdrouter_icmp_10 |
Verify ICMP Time Exceeded packet is sent when incoming UDP TTL is 1 |
step 1. Set the IP TTL of outbound packets to 1
step 2. Forward an UDP packet from a LAN client to the WAN
step 3. Verify ICMP Time Exceeded packet is sent to initial LAN host
step 4. Verify the ICMP Time Exceeded packet contains the IP header of the
original packet
References:
IETF RFC 792 "INTERNET CONTROL MESSAGE PROTOCOL"
https://tools.ietf.org/html/rfc792
| Test |
Module |
Name |
Synopsis |
Verify NAT translates IP address in ICMP Time Exceeded packet |
icmp.tcl |
cdrouter_icmp_11 |
Verify NAT translates IP address in ICMP Time Exceeded packet |
step 1. Forward a UDP packet from a LAN client to the WAN
step 2. Verify packet is received on WAN side
step 3. Send ICMP Time Exceeded packet with original UDP packet as data
step 4. Verify ICMP Time Exceeded packet is received by LAN host
step 5. Verify that the contents of the original IP packet included
in the ICMP Time Exceeded packet are properly translated by NAT
step 6. The following fields are verified:
IP length (length should not change)
IP ID (unchanged)
IP source address (translated by NAT)
IP destination address (unchanged)
IP checksum (recomputed by NAT)
UDP source port (translated by NAT)
UDP destination port (unchanged)
NOTE: If an implementation changes the IPv4 ID field of an outgoing
IPv4 packet, the returned IP header may contain a different ID field
than the original packet. The IP header ID field verification can be
skipped by configuring:
References:
IETF RFC 1631 "The IP Network Address Translator (NAT)" Section 3.3: Header Manipulations
If an ICMP message is passed through NAT, it may require two address
modifications and three checksum modifications. This is because most ICMP
messages contain part of the original IP packet in the body.
https://tools.ietf.org/html/rfc1631#section-3.3
| Test |
Module |
Name |
Synopsis |
Verify NAT translates IP address in ICMP Destination Unreachable with code port unreachable |
icmp.tcl |
cdrouter_icmp_12 |
Verify NAT translates IP address in ICMP Destination Unreachable with code port unreachable |
step 1. Forward a UDP packet from a LAN client to the WAN
step 2. Verify packet is received on WAN side
step 3. Send ICMP Destination Unreachable packet with original UDP packet as data
step 4. Verify ICMP Destination Unreachable is received by LAN host
step 5. Verify that the contents of the original IP packet included
in the ICMP Destination Unreachable message are translated by NAT
step 6. The following fields are verified:
IP length (length should not change)
IP ID (unchanged)
IP source address (translated by NAT)
IP destination address (unchanged)
IP checksum (recomputed by NAT)
UDP source port (translated by NAT)
UDP destination port (unchanged)
NOTE: If an implementation changes the IPv4 ID field of an outgoing
IPv4 packet, the returned IP header may contain a different ID field
than the original packet. The IP header ID field verification can be
skipped by configuring:
References:
IETF RFC 1631 "The IP Network Address Translator (NAT)" Section 3.3: Header Manipulations
If an ICMP message is passed through NAT, it may require two address
modifications and three checksum modifications. This is because most ICMP
messages contain part of the original IP packet in the body.
https://tools.ietf.org/html/rfc1631#section-3.3
| Test |
Module |
Name |
Synopsis |
Verify NAT translates IP address in ICMP Destination Unreachable with code fragmentation needed |
icmp.tcl |
cdrouter_icmp_13 |
Verify NAT translates IP address in ICMP Destination Unreachable with code fragmentation needed |
step 1. Forward a UDP packet from a LAN client to the WAN with IPv4 DF=1
step 2. Verify packet is received on WAN side
step 3. Send ICMP Destination Unreachable with code 4 Fragmentation needed and
DF set packet with original UDP packet as data
step 4. Verify ICMP Destination Unreachable is received by LAN host
step 5. Verify that the contents of the original IP packet included
in the ICMP Destination Unreachable message are translated by NAT
step 6. The following fields are verified:
IP length (length should not change)
IP ID (unchanged)
IP source address (translated by NAT)
IP destination address (unchanged)
IP checksum (recomputed by NAT)
UDP source port (translated by NAT)
UDP destination port (unchanged)
NOTE: If an implementation changes the IPv4 ID field of an outgoing
IPv4 packet, the returned IP header may contain a different ID field
than the original packet. The IP header ID field verification can be
skipped by configuring:
References:
IETF RFC 1631 "The IP Network Address Translator (NAT)" Section 3.3: Header Manipulations
If an ICMP message is passed through NAT, it may require two address
modifications and three checksum modifications. This is because most ICMP
messages contain part of the original IP packet in the body.
https://tools.ietf.org/html/rfc1631#section-3.3
| Test |
Module |
Name |
Synopsis |
Verify NAT translates IP address in outbound ICMP Destination Unreachable with code port unreachable |
icmp.tcl |
cdrouter_icmp_14 |
Verify NAT translates IP address in outbound ICMP Destination Unreachable with code port unreachable |
step 1. Forward a UDP packet from LAN client to the WAN
step 2. Verify packet is received on WAN side
step 3. Forward a UDP packet from the WAN to the LAN client
step 4. Send ICMP Destination Unreachable packet with original UDP packet as data
step 5. Verify ICMP Destination Unreachable is received by WAN host
step 6. Verify that the contents of the original IP packet included
in the ICMP Destination Unreachable message are translated by NAT
step 7. The following fields are verified:
IP length (length should not change)
IP ID (unchanged)
IP source address (unchanged)
IP destination address (translated by NAT)
IP checksum (recomputed by NAT)
UDP source port (unchanged)
UDP destination port (translated by NAT)
NOTE: If an implementation changes the IPv4 ID field of an outgoing
IPv4 packet, the returned IP header may contain a different ID field
than the original packet. The IP header ID field verification can be
skipped by configuring:
References:
IETF RFC 1631 "The IP Network Address Translator (NAT)" Section 3.3: Header Manipulations
If an ICMP message is passed through NAT, it may require two address
modifications and three checksum modifications. This is because most ICMP
messages contain part of the original IP packet in the body.
https://tools.ietf.org/html/rfc1631#section-3.3
| Test |
Module |
Name |
Synopsis |
Verify router supports Path MTU Discovery over WAN interface |
icmp.tcl |
cdrouter_icmp_20 |
Verify router supports Path MTU Discovery over WAN interface |
step 1. Send 1500 byte UDP packet with IP Don't Fragment Flag = 1
step 2. Check for an ICMP Destination Unreachable packet with code = 4
step 3. Repeat process 2 more times until until an ICMP Destination
Unreachable packet is received, or all 3 packets are sent
step 4. If an ICMP Destination Unreachable packet was sent, verify that
the code value is 4 and verify the MTU value in the ICMP header
step 5. Reduce the UDP packet size by 1 byte and repeat the process
until no ICMP Destination Unreachable packet is sent
step 6. When a packet size is found that does not generate an
ICMP Destination Unreachable message, verify packets can be
forwarded using this packet size
step 7. Verify the final MTU size is the same as the MTU size
reported in the ICMP Destination Unreachable packet
NOTE: This test starts with an initial MTU of 1500. If the WAN interface
already supports this MTU (DHCP), then this test will pass without
exercising the real part of Path MTU Discovery.
NOTE: Some devices rate limit the number of ICMP packets that may be sent.
This test will send 3 UDP packets over a 15 second window in order to
generate an ICMP Destination Unreachable packet. If the router under test
uses rate limiting on ICMP packets, it must allow at least one ICMP packet
every 10 seconds.
References:
IETF RFC 1191 "Path MTU Discovery"
https://tools.ietf.org/html/rfc1191
| Test |
Module |
Name |
Synopsis |
Verify ICMP Time Exceeded packet is sent when incoming TCP TTL is 1 |
icmp.tcl |
cdrouter_icmp_30 |
Verify ICMP Time Exceeded packet is sent when incoming TCP TTL is 1 |
step 1. Set the IP TTL of outbound packets to 1
step 2. Forward a TCP Syn packet from a LAN client to the WAN
step 3. Verify ICMP Time Exceeded packet is sent to initial LAN host
step 4. Verify the ICMP Time Exceeded packet contains the IP header of the
original packet
Additional Information on TCP Traceroute:
https://www.freebsd.org/cgi/man.cgi?query=tcptraceroute
References:
IETF RFC 792 "INTERNET CONTROL MESSAGE PROTOCOL"
https://tools.ietf.org/html/rfc792
firewall.tcl
Firewall tests including port scans
| Test |
Module |
Name |
Synopsis |
Inbound TCP connections to public side HTTP port are blocked |
firewall.tcl |
cdrouter_firewall_1 |
Inbound TCP connections to public side HTTP port are blocked |
step 1. Initiate a WAN TCP connection to the router's public IP at port 80
step 2. Verify the connection is not established
step 3. Initiate a WAN TCP connection to the router's private IP at port 80
step 4. Verify the connection is not established
step 5. Initiate a LAN TCP connection to the router's private IP at port 80
step 6. Verify the connection is established
| Test |
Module |
Name |
Synopsis |
Inbound TCP connections to LAN hosts are blocked |
firewall.tcl |
cdrouter_firewall_2 |
Inbound TCP connections to LAN hosts are blocked |
step 1. Initiate a WAN TCP connection to a LAN client address
step 2. Verify the connection is not established
| Test |
Module |
Name |
Synopsis |
DHCP server ignores DHCP client request from the WAN |
firewall.tcl |
cdrouter_firewall_10 |
DHCP server ignores DHCP client request from the WAN |
step 1. Start new DHCP client on WAN interface
step 2. Verify new client does not obtain lease for IP address
| Test |
Module |
Name |
Synopsis |
DNS requests from the WAN are ignored by DNS proxy or relay |
firewall.tcl |
cdrouter_firewall_12 |
DNS requests from the WAN are ignored by DNS proxy or relay |
step 1. Initiate a DNS request from the LAN client to a known host
step 2. Verify a valid DNS response is received
step 3. Initiate a DNS request from remoteHost to the router's WAN IP
for the same host name
step 4. Verify that a DNS response is not received
NOTE: This test case will be skipped if the router has a UDP
virtual service configured on the DNS port 53.
| Test |
Module |
Name |
Synopsis |
Perform TCP port scan test on router's public WAN IP address |
firewall.tcl |
cdrouter_firewall_100 |
Perform TCP port scan test on router’s public WAN IP address |
step 1. Send ARP Replies for all LAN hosts and static LAN hosts
step 2. Send TCP SYN packets from WAN to each port in the port scan range
step 3. Verify packets are not forwarded to LAN
step 4. Verify the router does not accept the TCP connection or
send a RST for the TCP connection unless the port has
been configured as an open or closed port
step 5. Do not flag ports that have port forwarding configured
NOTE: The speed of the scan can be adjusted using the 'portScanDelay'
testvar. By default, it is set to 1. The value indicates the number of
milliseconds to wait in between the sending of each packet:
testvar portScanDelay 100
NOTE: The list of closed and open ports can be configured using the
'firewallTcpClosedPorts' and 'firewallTcpOpenPorts' testvars:
testvar firewallTcpClosedPorts "2323"
testvar firewallTcpOpenPorts "22 443"
| Test |
Module |
Name |
Synopsis |
Perform UDP port scan test on router's public WAN IP address |
firewall.tcl |
cdrouter_firewall_101 |
Perform UDP port scan test on router’s public WAN IP address |
step 1. Send ARP replys for all LAN hosts and static LAN hosts
step 2. Send UDP packets from WAN to each port in the port scan range
step 3. Verify packets are not forwarded to LAN
step 4. Verify no ICMP Destination Unreachable messages or UDP Echo Replies
are received unless UDP port is configured as an open or close port
step 5. Do not flag ports that have port forwarding configured
NOTE: A warning will still be issued if a packet is forwarded if
it has been configured as a virtual service.
NOTE: The speed of the scan can be adjusted using the 'portScanDelay'
testvar. By default, it is set to 1. The value indicates the number of
milliseconds to wait in between the sending of each packet:
testvar portScanDelay 100
NOTE: The list of closed and open ports can be configured using the
'firewallUdpClosedPorts' and 'firewallUdpOpenPorts' testvars:
testvar firewallUdpClosedPorts "2323"
testvar firewallUdpOpenPorts "22 443"
| Test |
Module |
Name |
Synopsis |
Perform TCP fragmentation port scan test on router's public WAN IP address |
firewall.tcl |
cdrouter_firewall_110 |
Perform TCP fragmentation port scan test on router’s public WAN IP address |
step 1. Send ARP Replies for all LAN hosts and static LAN hosts
step 2. Set the IPv4 fragmentation size to 28 bytes
step 3. Send TCP SYN packets from WAN to each port in the port scan range
step 4. Verify packets are not forwarded to LAN
step 5. Verify the router does not accept the TCP connection or
send a RST for the TCP connection unless the port has
been configured as an open or closed port
step 6. Do not flag ports that have port forwarding configured
NOTE: A warning will still be issued if a packet is forwarded if
it has been configured as a virtual service.
NOTE: The speed of the scan can be adjusted using the 'portScanDelay'
testvar. By default, it is set to 1. The value indicates the number of
milliseconds to wait in between the sending of each packet:
testvar portScanDelay 100
NOTE: The list of closed and open ports can be configured using the
'firewallTcpClosedPorts' and 'firewallTclOpenPorts' testvars:
testvar firewallTcpClosedPorts "2323"
testvar firewallTcpOpenPorts "22 443"
| Test |
Module |
Name |
Synopsis |
Verify firewall blocks/accepts piggyback TCP SYN connections from WAN |
firewall.tcl |
cdrouter_firewall_301 |
Verify firewall blocks/accepts piggyback TCP SYN connections from WAN |
step 1. Send a TCP SYN from LAN host to IP address on WAN
step 2. Send a TCP SYN from the WAN host to the original LAN host
using the same TCP source port
step 3. If the router blocks simultaneous TCP SYNs through NAT
(testvar 'natSimultaneousTcp' is set to no), verify the TCP
SYN from the WAN is dropped
OR
If the router supports simultaneous TCP SYN through NAT
(testvar 'natSimultaneousTcp' is set to yes), verify the TCP
SYN from the WAN is forwarded to the LAN
step 4. Repeat step 1 using new TCP port numbers
step 5. Send a TCP SYN from the WAN host to the original LAN host
using a new TCP source port
step 6. Verify the TCP SYN from the WAN is dropped
NOTE: This test verifies that the firewall only allows TCP packets
for established TCP sessions. If simultaneous TCP open is supported through
NAT, this test will verify that TCP SYN packets from the WAN are forwarded
to the LAN. If simultaneous TCP open through NAT is not supported, the
test will verify that no TCP SYN packets are allowed from the WAN to the
LAN for sessions that have been initiated from the LAN.
NOTE: This test also verifies that the NAT implementation is
Port Restricted and that returning packets must have the same TCP
source used to created the NAT binding.
NOTE: Steps 4-6 of this test will be skipped if natMode is not
"port-restricted".
| Test |
Module |
Name |
Synopsis |
Verify outbound packets are not forwarded if the source address is not a prefix of the interior network |
firewall.tcl |
cdrouter_firewall_508 |
Verify outbound packets are not forwarded if the source address is not a prefix of the interior network |
step 1. Create a new LAN client
step 2. Assign an address outside of lanIp/lanMask
step 3. Send traffic to the WAN from the martian source address
step 4. Verify traffic is not forwarded
step 5. Assign an address from the private-use address block outside lanIp/lanMask
step 6. Send traffic to the WAN from the martian source address
step 7. Verify traffic is not forwarded
NOTE: This test ensures that the random martian address assigned
to the LAN client in step 2 is outside of lanIp/lanMask, does not
match any static routes configured with staticRouteLanNetwork and
is not within any of the following reserved IP ranges: 0.0.0.0/8,
127.0.0.0/8, 169.254.0.0/16, 192.88.99.0/24, 224.0.0.0/4,
240.0.0.0/4, 255.255.255.255/32.
References:
IETF RFC 3704 "Ingress Filtering for Multihomed Networks"
https://tools.ietf.org/html/rfc3704
firewall-out.tcl
Firewall tests for limiting outbound access to services
| Test |
Module |
Name |
Synopsis |
Verify CPE does not forward outbound TCP packets to ports that have been administratively blocked |
firewall-out.tcl |
cdrouter_firewall_outbound_1 |
Verify CPE does not forward outbound TCP packets to ports that have been administratively blocked |
step 1. Configure the DUT to block outbound access from the LAN to specific TCP ports
step 2. Send a TCP SYN packet from the LAN to each blocked port
step 3. Verify the DUT does not forward TCP packets to any of the blocked ports
The firewallOutBlockedTcpPorts testvar is used to determine the list of TCP ports
that the DUT has been configured to block access to.
| Test |
Module |
Name |
Synopsis |
Verify CPE does not forward outbound UDP packets to ports that have been administratively blocked |
firewall-out.tcl |
cdrouter_firewall_outbound_2 |
Verify CPE does not forward outbound UDP packets to ports that have been administratively blocked |
step 1. Configure the DUT to block outbound access from the LAN to specific UDP ports
step 2. Send a UDP packet from the LAN to each blocked port
step 3. Verify the DUT does not forward UDP packets to any of the blocked ports
The firewallOutBlockedUdpPorts testvar is used to determine the list of UDP ports
that the DUT has been configured to block access to.
| Test |
Module |
Name |
Synopsis |
Verify CPE does not forward outbound IP packets for protocols that have been administratively blocked |
firewall-out.tcl |
cdrouter_firewall_outbound_3 |
Verify CPE does not forward outbound IP packets for protocols that have been administratively blocked |
step 1. Configure the DUT to block outbound access from the LAN to specific IP Protocol types
step 2. Send an IP packet from the LAN to the WAN for each blocked IP protocol
step 3. Verify the DUT does not forward any of the blocked IP protocols
The firewallOutBlockedIpProtos testvar is used to determine the list of IP Protocol types
that the DUT has been configured to block access to.
apps.tcl
Application layer gateway (ALG) tests for FTP, DNS, TFTP, SMTP, POP3, MSN, RTSP and others
| Test |
Module |
Name |
Synopsis |
Verify router supports the active mode FTP PORT command |
apps.tcl |
cdrouter_app_2 |
Verify router supports the active mode FTP PORT command |
step 1. Initiate an outbound tcp connection to FTP server port
step 2. Verify the connection is established
step 3. Send the FTP port command using all upper case letters
step 4. Verify router translates port command using router's address
step 5. Initiate inbound TCP connection for FTP data connection
step 6. Verify inbound TCP connection is established
step 7. Close both connections
References:
IETF RFC 959 "FILE TRANSFER PROTOCOL (FTP)" Section 5.3: COMMANDS
https://tools.ietf.org/html/rfc959#section-5.3
| Test |
Module |
Name |
Synopsis |
Multiple FTP connections using the same source port |
apps.tcl |
cdrouter_app_3 |
Multiple FTP connections using the same source port |
step 1. Set up second host using same source ports as original host
step 2. Initiate an outbound TCP connection to FTP server port
step 3. Verify the connection is established
step 4. Build the FTP PORT command for the LAN client
step 5. Start up second host on LAN
step 6. Initate outbound connection from second LAN host to FTP server
using same source port as FTP PORT command
step 7. Send the FTP PORT command on first connection
step 8. Verify router translates FTP PORT command using router's address
step 9. Initiate inbound TCP connection for FTP data connection
step 10. Verify inbound TCP connection is established
step 11. Close both connections
References:
IETF RFC 959 "FILE TRANSFER PROTOCOL (FTP)" Section 5.3: COMMANDS
https://tools.ietf.org/html/rfc959#section-5.3
| Test |
Module |
Name |
Synopsis |
Connections opened for FTP PORT command check for correct IPv4 address |
apps.tcl |
cdrouter_app_10 |
Connections opened for FTP PORT command check for correct IPv4 address |
step 1. Initiate an outbound FTP connection to FTP server port
step 2. Verify the connection is established
step 3. Send the FTP port command
step 4. Verify router translates port command using router's address
step 5. From new host, attempt inbound TCP connection for FTP data connection
step 6. Verify inbound TCP connection is not established
step 7. Close both connections
References:
IETF RFC 959 "FILE TRANSFER PROTOCOL (FTP)" Section 5.3: COMMANDS
https://tools.ietf.org/html/rfc959#section-5.3
| Test |
Module |
Name |
Synopsis |
Verify FTP PORT command succeeds when TCP segment is retransmitted |
apps.tcl |
cdrouter_app_11 |
Verify FTP PORT command succeeds when TCP segment is retransmitted |
step 1. Initiate an outbound TCP connection to FTP server port
step 2. Verify the connection is established
step 3. Configure WAN side server to ignore TCP packets
step 4. Send the FTP PORT command using all upper case letters
step 5. Wait five seconds and retransmit last TCP segment
step 6. Verify router translates port command using router's address
step 5. Initiate inbound TCP connection for FTP data connection
step 7. Verify inbound TCP connection is established
step 8. Close both connections
References:
IETF RFC 959 "FILE TRANSFER PROTOCOL (FTP)" Section 5.3: COMMANDS
https://tools.ietf.org/html/rfc959#section-5.3
| Test |
Module |
Name |
Synopsis |
Verify FTP PORT translation stays the same when TCP segment is retransmitted |
apps.tcl |
cdrouter_app_12 |
Verify FTP PORT translation stays the same when TCP segment is retransmitted |
step 1. Initiate an outbound TCP connection to FTP server port
step 2. Verify the connection is established
step 3. Configure WAN side server to ignore TCP packets
step 4. Send the FTP port command
step 5. Verify the FTP PORT command is translated
step 6. Wait five seconds and retransmit last TCP segment
step 7. Verify the FTP PORT command is translated to the same ports
step 8. Initiate inbound TCP connection for FTP data connection
step 9. Verify inbound TCP connection is established
step 10. Close both connections
References:
IETF RFC 959 "FILE TRANSFER PROTOCOL (FTP)" Section 5.3: COMMANDS
https://tools.ietf.org/html/rfc959#section-5.3
| Test |
Module |
Name |
Synopsis |
Verify router closes public ports opened with the FTP PORT command |
apps.tcl |
cdrouter_app_14 |
Verify router closes public ports opened with the FTP PORT command |
step 1. Initiate an outbound TCP connection to FTP server port
step 2. Verify the connection is established
step 3. Send the FTP PORT command using all upper case letters
step 4. Verify router translates FTP PORT command using router's address
step 5. Close the outbound TCP connection
step 6. Wait ftpPortTimeout seconds for inbound port to be closed
step 7. Initiate inbound TCP connection for FTP data connection
step 8. Verify inbound TCP connection is blocked
NOTE: The FTP PORT command will cause the router to open inbound ports for
incoming FTP data connections. When the FTP control session is closed, the
router should also close any inbound ports that have been opened.
NOTE: The FTP PORT clean up interval can be configued using the
ftpPortTimeout testvar.
References:
IETF RFC 959 "FILE TRANSFER PROTOCOL (FTP)" Section 5.3: COMMANDS
https://tools.ietf.org/html/rfc959#section-5.3
| Test |
Module |
Name |
Synopsis |
Verify router supports the active mode FTP EPRT command |
apps.tcl |
cdrouter_app_15 |
Verify router supports the active mode FTP EPRT command |
step 1. Initiate an outbound TCP connection to FTP server port
step 2. Verify the connection is established
step 3. Send the FTP EPRT command using all upper case letters
step 4. Verify router translates EPRT command using router's address
step 5. Initiate inbound TCP connection for FTP data connection
step 6. Verify inbound TCP connection is established
step 7. Close both connections
References:
IETF RFC 2428 "FTP Extensions for IPv6 and NATs" Section 2: The EPRT Command
https://tools.ietf.org/html/rfc2428#section-2
| Test |
Module |
Name |
Synopsis |
Verify translation of EPRT command accepts non default delimiters |
apps.tcl |
cdrouter_app_16 |
Verify translation of EPRT command accepts non default delimiters |
step 1. Initiate an outbound TCP connection to FTP server port
step 2. Verify the connection is established
step 3. Send the FTP EPRT command using delimiter character '~'
step 4. Verify router translates EPRT command using router's address
step 5. Initiate inbound TCP connection for FTP data connection
step 6. Verify inbound TCP connection is established
step 7. Close both connections
NOTE: The FTP ALG on the device may change the delimiter back to the
default delimiter character '|'.
References:
IETF RFC 2428 "FTP Extensions for IPv6 and NATs" Section 2: The EPRT Command
https://tools.ietf.org/html/rfc2428#section-2
| Test |
Module |
Name |
Synopsis |
Verify router supports the passive mode FTP PASV command |
apps.tcl |
cdrouter_app_17 |
Verify router supports the passive mode FTP PASV command |
step 1. Initiate an outbound tcp connection to FTP server port
step 2. Verify the connection is established
step 3. Send the FTP PASV command using all upper case letters
step 4. Verify PASV command is received on the WAN
step 5. Send PASV response that includes server IP and port
step 6. Verify the server IP and port is not translated on the LAN
step 7. Initiate outbound TCP connection for FTP data connection
step 8. Verify inbound TCP connection is established
step 9. Close both connections
References:
IETF RFC 959 "FILE TRANSFER PROTOCOL (FTP)" Section 5.3: COMMANDS
https://tools.ietf.org/html/rfc959#section-5.3
IETF RFC 1123 "Requirements for Internet Hosts -- Application and Support" Section 4.1.2.6: PASV Command: RFC-959 Section 4.1.2
A server-FTP MUST implement the PASV command.
If multiple third-party transfers are to be executed during
the same session, a new PASV command MUST be issued before
each transfer command, to obtain a unique port pair.
IMPLEMENTATION:
The format of the 227 reply to a PASV command is not
well standardized. In particular, an FTP client cannot
assume that the parentheses shown on page 40 of RFC 959
will be present (and in fact, Figure 3 on page 43 omits
them). Therefore, a User-FTP program that interprets
the PASV reply must scan the reply for the first digit
of the host and port numbers.
Note that the host number h1,h2,h3,h4 is the IP address
of the server host that is sending the reply, and that
p1,p2 is a non-default data transfer port that PASV has
assigned.
https://tools.ietf.org/html/rfc1123#section-4.1.2.6
| Test |
Module |
Name |
Synopsis |
Verify router supports the passive mode FTP EPSV command |
apps.tcl |
cdrouter_app_18 |
Verify router supports the passive mode FTP EPSV command |
step 1. Initiate an outbound tcp connection to FTP server port
step 2. Verify the connection is established
step 3. Send the FTP EPSV command using all upper case letters
step 4. Verify EPSV command is received on the WAN
step 5. Send EPSV response that includes server IP and port
step 6. Verify the server IP and port is not translated on the LAN
step 7. Initiate outbound TCP connection for FTP data connection
step 8. Verify inbound TCP connection is established
step 9. Close both connections
References:
IETF RFC 2428 "FTP Extensions for IPv6 and NATs"
https://tools.ietf.org/html/rfc2428
| Test |
Module |
Name |
Synopsis |
Verify DNS queries to router are forwarded to real DNS server |
apps.tcl |
cdrouter_app_20 |
Verify DNS queries to router are forwarded to real DNS server |
step 1. Initiate a DNS query to the router's LAN ip address
step 2. Verify the query is received by real DNS server on the WAN side
step 3. The query may be received by the primary or backup DNS server
step 4. Send a return response back to LAN
step 5. Verify the response is received by the LAN client
NOTE: The router must support some type of DNS relay or proxy to pass this
test case.
| Test |
Module |
Name |
Synopsis |
Verify DNS queries sent to primary DNS server |
apps.tcl |
cdrouter_app_21 |
Verify DNS queries sent to primary DNS server |
step 1. Initiate a DNS query to the primary DNS server from the LAN
step 2. Verify the query is received by real DNS server on the WAN side
step 3. Depending on the implementation, the query may be received by
the primary or backup DNS server
step 4. Send a response to the LAN
step 5. Verify the response is received by the LAN client
| Test |
Module |
Name |
Synopsis |
Verify DNS queries sent to backup DNS server |
apps.tcl |
cdrouter_app_22 |
Verify DNS queries sent to backup DNS server |
step 1. Initiate a DNS query to the backup DNS server from the LAN
step 2. Verify the query is received by real DNS server on the WAN side
step 3. Depending on the implementation, the query may be received by
the primary or backup DNS server
step 4. Send a response to the LAN
step 5. Verify the response is received by the LAN client.
| Test |
Module |
Name |
Synopsis |
Verify DNS relay on router fails over to backup DNS server |
apps.tcl |
cdrouter_app_25 |
Verify DNS relay on router fails over to backup DNS server |
step 1. Configure the primary DNS server to ignore all DNS requests
step 2. Initiate a DNS query to the router's LAN ip address
step 3. Verify the query is received by the backup DNS server on the WAN side
step 4. Send a response back to the LAN
step 5. Verify the response is received by the LAN client
NOTE: Some routers will alternate sending DNS queries between the configured
or learned DNS servers. Other routers will send queries to all of the
configured or learned DNS servers at the same time. This test will continue
to send DNS queries for up to 120 seconds by default. This time interval may
be changed by configuring the testvar dnsRelayFailover to the number of
seconds to wait before failover should happen.
| Test |
Module |
Name |
Synopsis |
Verify DNS relay on router fails over to backup DNS server (using same ID for retransmissions) |
apps.tcl |
cdrouter_app_26 |
Verify DNS relay on router fails over to backup DNS server (using same ID for retransmissions) |
step 1. Configure the primary DNS server to ignore all DNS requests
step 2. Initiate a DNS query to the router's LAN ip address
step 3. Verify the query is received by the backup DNS server on the WAN side
step 4. Send a response back to the LAN
step 5. Verify the response is received by the LAN client
NOTE: Some routers will alternate sending DNS queries between the configured
or learned DNS servers. Other routers will send queries to all of the
configured or learned DNS servers at the same time. This test will continue
to send DNS queries for up to 120 seconds by default. This time interval may
be changed by configuring the testvar dnsRelayFailover to the number of
seconds to wait before failover should happen.
NOTE: For this test, the LAN client will use the same DNS transaction ID for
all DNS query retransmissions.
| Test |
Module |
Name |
Synopsis |
Verify DNS relay on router fails over to third DNS server |
apps.tcl |
cdrouter_app_27 |
Verify DNS relay on router fails over to third DNS server |
step 1. Configure the primary and secondary DNS servers to ignore all DNS requests
step 2. Initiate a DNS query to the router's LAN ip address
step 3. Verify the query is received by the third DNS server on the WAN side
step 4. Send a response back to the LAN
step 5. Verify the response is received by the LAN client
NOTE: Some routers will alternate sending DNS queries between the configured
or learned DNS servers. Other routers will send queries to all of the
configured or learned DNS servers at the same time. This test will continue
to send DNS queries for up to 120 seconds by default. This time interval may
be changed by configuring the testvar dnsRelayFailover to the number of
seconds to wait before failover should happen.
| Test |
Module |
Name |
Synopsis |
Verify DNS relay on router fails over to third DNS server (using same ID for retransmissions) |
apps.tcl |
cdrouter_app_28 |
Verify DNS relay on router fails over to third DNS server (using same ID for retransmissions) |
step 1. Configure the primary and secondary DNS server to ignore all DNS requests
step 2. Initiate a DNS query to the router's LAN ip address
step 3. Verify the query is received by the backup DNS server on the WAN side
step 4. Send a response back to the LAN
step 5. Verify the response is received by the LAN client
NOTE: Some routers will alternate sending DNS queries between the configured
or learned DNS servers. Other routers will send queries to all of the
configured or learned DNS servers at the same time. This test will continue
to send DNS queries for up to 120 seconds by default. This time interval may
be changed by configuring the testvar dnsRelayFailover to the number of
seconds to wait before failover should happen.
NOTE: For this test, the LAN client will use the same DNS transaction ID for
all DNS query retransmissions.
| Test |
Module |
Name |
Synopsis |
Verify DNS queries sent directly to a 3rd party DNS server |
apps.tcl |
cdrouter_app_30 |
Verify DNS queries sent directly to a 3rd party DNS server |
step 1. Create a new DNS server on the WAN with a unique IP address
step 2. Initiate a DNS query to to the new DNS server
step 3. Verify the query is received by the DNS server on the WAN side
step 4. Send a response back to the LAN
step 5. Verify the response is received by the LAN client
NOTE: This test verifies that DNS clients and DNS tools running on a LAN
client can initiate DNS queries to a third party DNS server that has not
been configured on the router nor learned by the router.
NOTE: If the testvar dnsCaptive is set to yes, the test will expect DNS
queries to be sent to the original WAN side DNS servers and not the 3rd
party DNS server.
| Test |
Module |
Name |
Synopsis |
Verify router supports wrapping of TCP sequence number for FTP transfers |
apps.tcl |
cdrouter_app_100 |
Verify router supports wrapping of TCP sequence number for FTP transfers |
step 1. Set the initial TCP sequence number to 0xfffffffc
step 2. Initiate an outbound TCP connection to FTP server port
step 3. Verify the connection is established
step 4. Send the FTP PORT command using all upper case letters
step 5. Verify router translates FTP PORT command using router's address
step 6. Verify the sequence number has correctly wrapped
step 7. Initiate inbound TCP connection for FTP data connection
step 8. Verify inbound TCP connection is established
step 9. Close both connections
step 10. Repeat for initial TCP sequence numbers 0xfffffffc - 0x00000001
| Test |
Module |
Name |
Synopsis |
Verify HTTPS session through the router |
apps.tcl |
cdrouter_app_110 |
Verify HTTPS session through the router |
step 1. Initiate an outbound TCP connection to HTTPS server
step 2. Verify the TCP connection is established
step 3. Verify the IPv4 source address on the WAN side is the router's address
step 4. Verify the TLS session is established
step 5. Send HTTPS GET request to server
step 6. Verify HTTPS response is received
step 7. Close TCP connection from LAN side
| Test |
Module |
Name |
Synopsis |
Verify SMTP session through the router |
apps.tcl |
cdrouter_app_120 |
Verify SMTP session through the router |
step 1. Initiate an outbound TCP connection to SMTP server
step 2. Send email message using SMTP server
step 3. Verify SMTP server correctly receives email message
step 4. Close SMTP session from LAN side
References:
IETF RFC 821 "SIMPLE MAIL TRANSFER PROTOCOL"
https://tools.ietf.org/html/rfc821
| Test |
Module |
Name |
Synopsis |
Verify POP3 session through the router |
apps.tcl |
cdrouter_app_122 |
Verify POP3 session through the router |
step 1. Initiate an outbound TCP connection to POP3 server
step 2. Retreive email messages using POP3 protocol
step 3. Verify POP3 server correctly returns email messages
step 4. Close POP3 session from LAN side
References:
IETF RFC 1939 "Post Office Protocol - Version 3"
https://tools.ietf.org/html/rfc1939
| Test |
Module |
Name |
Synopsis |
Verify TFTP session through the router |
apps.tcl |
cdrouter_app_124 |
Verify TFTP session through the router |
step 1. Startup a TFTP server on the WAN
step 2. Initiate an outbound TFTP connection to TFTP server from LAN
step 3. Send TFTP GET to receive file via TFTP
step 4. Verify TFTP server correctly returns file via TFTP
step 5. Close TFTP session from LAN side
References:
IETF RFC 1350 "THE TFTP PROTOCOL (REVISION 2)"
https://tools.ietf.org/html/rfc1350
| Test |
Module |
Name |
Synopsis |
Verify NTP session through the router |
apps.tcl |
cdrouter_app_126 |
Verify NTP session through the router |
step 1. Initiate an outbound NTP connection to NTP server
step 2. Verify NTP request is sent to the WAN
step 3. Verify NTP response is sent to LAN client
| Test |
Module |
Name |
Synopsis |
Verify STUN session through the router |
apps.tcl |
cdrouter_app_130 |
Verify STUN session through the router |
step 1. Initiate an outbound STUN Binding Request to remoteHost
step 2. Verify STUN Binding Response is received
step 3. Verify the STUN MAPPED-ADDRESS matches the expected NAT Address
References:
IETF RFC 3489 "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)"
https://tools.ietf.org/html/rfc3489
| Test |
Module |
Name |
Synopsis |
Verify authenticated STUN session through the router |
apps.tcl |
cdrouter_app_131 |
Verify authenticated STUN session through the router |
step 1. Configure STUN server and client to use authentication
step 2. Initiate an outbound STUN Binding Request to remoteHost
step 3. STUN server should sent back a 401 Binding Error Response
step 4. STUN client retransmits Binding Request using message-integrity attribute
step 5. Verify STUN Binding Response is received
step 6. Verify the STUN MAPPED-ADDRESS matches the expected NAT Address
References:
IETF RFC 3489 "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)"
https://tools.ietf.org/html/rfc3489
| Test |
Module |
Name |
Synopsis |
Verify IPv4 L2GRE session through the router |
apps.tcl |
cdrouter_app_140 |
Verify IPv4 L2GRE session through the router |
step 1. Enable L2GRE endpoint on the LAN client
step 2. Create a new IPv4 address on the WAN for the other L2GRE endpoint
step 3. Initiate an ICMP ping from LAN to WAN using L2GRE tunnel
step 4. Verify the ICMP is successful
References:
IETF RFC 2784 "Generic Routing Encapsulation (GRE)"
https://tools.ietf.org/html/rfc2784
| Test |
Module |
Name |
Synopsis |
Verify router translates MSN File Transfer Invite messages |
apps.tcl |
cdrouter_app_302 |
Verify router translates MSN File Transfer Invite messages |
step 1. Open a TCP connection to the MSN Dispatch Server at port 1863
step 2. After login, look for XFR command to MSN Notification Server
step 3. Open a TCP connection to the MSN Notification Server
step 4. Login and send XFR command for MSN Switchboard Server
step 5. Look for XFR command to MSN Switchboard Server
step 6. Open a TCP connection from LAN client to MSN Switchboard Server on WAN
step 7. Send a MSN Invite message for a file transfer application
step 8. Send a MSN Accept message with LAN side IP address and port
step 9. Verify the MSN Accept message is received on the WAN side
step 10. Verify the IP address has been NAT translated
step 11. Verify an inbound TCP connection can be created to the LAN
client using the NAT translated IP and port number
| Test |
Module |
Name |
Synopsis |
Verify router translates MSN Voice Invite messages |
apps.tcl |
cdrouter_app_305 |
Verify router translates MSN Voice Invite messages |
step 1. Open a TCP connection to the MSN Dispatch Server at port 1863
step 2. After login, look for XFR command to MSN Notification Server
step 3. Open a TCP connection to the MSN Notification Server
step 4. Login and send XFR command for MSN Switchboard Server
step 5. Look for XFR command to MSN Switchboard Server
step 6. Open a TCP connection from LAN client to MSN Switchbaord Server on WAN
step 7. Send a MSN Invite message for a voice application
step 8. Send a MSN Accept message with LAN side IP address and port
step 9. Verify the MSN accept message is received on the WAN side
step 10. Verify the IP address has been NAT translated
| Test |
Module |
Name |
Synopsis |
Verify router does not modify MSN fields related to NAT detection |
apps.tcl |
cdrouter_app_310 |
Verify router does not modify MSN fields related to NAT detection |
step 1. Open a TCP connection to the MSN Dispatch Server at port 1863
step 2. After login, look for XFR command to MSN Notification Server
step 3. Open a TCP connection to the MSN Notification Server
step 4. Login and send XFR command for MSN Switchboard Server
step 5. Look for XFR command to MSN Switchboard Server
step 6. Open a TCP connection from LAN client to MSN Switchbaord Server on WAN
step 7. Send a MSN Invite message for a file transfer application
step 8. Send a MSN Accept message with LAN side IP address and port
Include IP-Address-Internal and PortX-Internal fields in MSN
Invite message
step 9. Verify the MSN Invite message is received on the WAN side
step 10. Verify the IP address has been NAT translated
step 11. Verify the IP-Address-Internal and PortX-Internal fields are not
translated by the MSN ALG
step 12. Verify an inbound TCP connection can be created to the LAN
client using the NAT translated IP and port number
| Test |
Module |
Name |
Synopsis |
Verify basic RTSP session with UDP transport |
apps.tcl |
cdrouter_rtsp_1 |
Verify basic RTSP session with UDP transport |
step 1. Establish TCP session from LAN client to RTSP server at port 554
step 2. Send a RTSP DESCRIBE for URL from client to server
step 3. Verify server response to client is code 200
step 4. Allocate 2 UDP ports on client for transport
step 5. Send a RTSP SETUP for URL from client to server using Transport
step 6. Verify RTSP server receives transport with port translations
step 7. Verify server response to client is code 200
step 8. Verify UDP forwarding from WAN to LAN for each AVP port in RTSP transport
step 9. Send RTSP TEARDOWN and close TCP session from LAN client
NOTE: The NAT ALG must handle translating the Transport field included in
the RTSP SETUP from the client.
References:
IETF RFC 2326 "Real Time Streaming Protocol (RTSP)"
https://tools.ietf.org/html/rfc2326
| Test |
Module |
Name |
Synopsis |
Verify basic RTSP session with UDP transport for multiple LAN hosts |
apps.tcl |
cdrouter_rtsp_2 |
Verify basic RTSP session with UDP transport for multiple LAN hosts |
step 1. Create a second DHCP host on the LAN
step 2. Setup RTSP transport for each client using the same src ports
step 3. For each client, verify UDP forwarding from WAN to LAN for each
AVP port in RTSP transport
step 4. For each client, send RTSP TEARDOWN and close TCP session from
LAN client
NOTE: The NAT ALG must handle translating the Transport field included in
the RTSP SETUP from the client.
References:
IETF RFC 2326 "Real Time Streaming Protocol (RTSP)"
https://tools.ietf.org/html/rfc2326
| Test |
Module |
Name |
Synopsis |
Verify RTSP transport is translated in both outbound and inbound directions |
apps.tcl |
cdrouter_rtsp_10 |
Verify RTSP transport is translated in both outbound and inbound directions |
step 1. Establish RTSP session to remoteHost on WAN
step 2. Send a RTSP DESCRIBE, SETUP, and PLAY to establish the transport
step 3. Verify the client port values are translated in the outbound direction
step 4. Verify the client port values are translated in the inbound direction
step 5. Verify UDP forwarding from WAN to LAN for each AVP port in RTSP transport
step 6. Send RTSP TEARDOWN and close TCP session from LAN client
References:
IETF RFC 2326 "Real Time Streaming Protocol (RTSP)"
https://tools.ietf.org/html/rfc2326
| Test |
Module |
Name |
Synopsis |
Verify RTSP port mapping is deleted after TEARDOWN and TCP close |
apps.tcl |
cdrouter_rtsp_20 |
Verify RTSP port mapping is deleted after TEARDOWN and TCP close |
step 1. Establish RTSP session to a remote host on the WAN
step 2. Send a RTSP DESCRIBE, SETUP, and PLAY to establish the transport
step 3. Verify UDP forwarding from WAN to LAN for each AVP port in RTSP transport
step 4. Send TEARDOWN from client and close TCP connection
step 5. Verify UDP forwarding fails from WAN to LAN for each AVP port in RTSP transport
Note: The amount of time between the RTSP TEARDOWN and the verification of
the port mappings can be adjusted using the testvar rtspTeardownDelay. This
defaults to 5 seconds.
References:
IETF RFC 2326 "Real Time Streaming Protocol (RTSP)"
https://tools.ietf.org/html/rfc2326
| Test |
Module |
Name |
Synopsis |
Verify RTSP port mapping is deleted after TEARDOWN and without TCP close |
apps.tcl |
cdrouter_rtsp_21 |
Verify RTSP port mapping is deleted after TEARDOWN and without TCP close |
step 1. Establish RTSP session to a remote host on the WAN
step 2. Send a RTSP DESCRIBE, SETUP, and PLAY to establish the transport
step 3. Verify UDP forwarding from WAN to LAN for each AVP port in RTSP transport
step 4. Send TEARDOWN from client
step 5. Do not close the TCP session from client to RTSP server
step 6. Verify UDP forwarding fails from WAN to LAN for each AVP port in RTSP transport
Note: RTSP clients are allowed to maintain persistent connections to the
RTSP server. They are not required to close the TCP session when a RTSP
session is ended.
Note: The amount of time between the RTSP TEARDOWN and the verification of
the port mappings can be adjusted using the testvar rtspTeardownDelay. This
defaults to 5 seconds.
References:
IETF RFC 2326 "Real Time Streaming Protocol (RTSP)"
https://tools.ietf.org/html/rfc2326
| Test |
Module |
Name |
Synopsis |
Verify RTSP port mappings still work when TCP connection is closed |
apps.tcl |
cdrouter_rtsp_22 |
Verify RTSP port mappings still work when TCP connection is closed |
step 1. Establish RTSP session to a remote host on the WAN
step 2. Send a RTSP DESCRIBE, SETUP, and PLAY to establish the transport
step 3. Verify UDP forwarding from WAN to LAN for each AVP port in RTSP transport
step 4. Do not send TEARDOWN from client to end the RTSP session
step 5. Close the TCP session from client to RTSP server
step 6. Verify UDP forwarding succeeds from WAN to LAN for each AVP port in RTSP transport
References:
IETF RFC 2326 "Real Time Streaming Protocol (RTSP)"
https://tools.ietf.org/html/rfc2326
| Test |
Module |
Name |
Synopsis |
Verify IPv4 destination in client transport SETUP is translated to public IP |
apps.tcl |
cdrouter_rtsp_30 |
Verify IPv4 destination in client transport SETUP is translated to public IP |
step 1. Establish TCP session from LAN client to RTSP server at port 554
step 2. Send a RTSP DESCRIBE for URL from client to server
step 3. Verify server response to client is code 200
step 4. Allocate 2 UDP ports on client for transport
step 5. Send a RTSP SETUP with transport that includes destination field
step 6. Verify server receives transport with transport IP address in destination field
step 7. Verify UDP forwarding from WAN to LAN for each AVP port in RTSP transport
step 8. Send RTSP TEARDOWN and close TCP session from LAN client
References:
IETF RFC 2326 "Real Time Streaming Protocol (RTSP)"
https://tools.ietf.org/html/rfc2326
| Test |
Module |
Name |
Synopsis |
Verify RTSP ALG supports persistent TCP connections |
apps.tcl |
cdrouter_rtsp_50 |
Verify RTSP ALG supports persistent TCP connections |
step 1. Establish RTSP session to remoteHost on WAN
step 2. Send a RTSP DESCRIBE, SETUP, and PLAY to establish the transport
step 3. Using the same TCP connection, setup a second RTSP session
step 4. Verify UDP forwarding from WAN to LAN for first session
step 5. Verify UDP forwarding from WAN to LAN for second session
step 6. Send RTSP TEARDOWN for first session
step 7. Send RTSP TEARDOWN for second session
step 8. Close TCP session from LAN client
References:
IETF RFC 2326 "Real Time Streaming Protocol (RTSP)" Section 1.1: Purpose
https://tools.ietf.org/html/rfc2326#section-1.1
IETF Internet-Draft draft-ietf-mmusic-2326bis-05 "TCP Fast Open"
https://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-05
| Test |
Module |
Name |
Synopsis |
Verify RTSP session with different IPv4 address for RTP media server |
apps.tcl |
cdrouter_rtsp_60 |
Verify RTSP session with different IPv4 address for RTP media server |
step 1. Create a new server on the WAN for the RTP media source
step 2. Establish TCP session from LAN client to RTSP server at port 554
step 3. Send a RTSP DESCRIBE for URL from client to server
step 4. Verify server response to client is code 200
step 5. Allocate 2 UDP ports on client for transport
step 6. Send a RTSP SETUP for URL from client to server using Transport
step 7. Verify RTSP server receives transport with port translations
step 8. Verify server response to client is code 200 along with
Transport: header that specifies a source IPv4 address
that is different from the RTSP server
step 9. Verify UDP forwarding from WAN to LAN for each AVP port in RTSP transport
using the IPv4 source address of the RTP media
step 10. Send RTSP TEARDOWN and close TCP session from LAN client
NOTE: The NAT ALG must handle translating the Transport field included in
the RTSP SETUP from the client.
References:
IETF RFC 2326 "Real Time Streaming Protocol (RTSP)"
https://tools.ietf.org/html/rfc2326
| Test |
Module |
Name |
Synopsis |
Verify RTSP session timeout for established session |
apps.tcl |
cdrouter_rtsp_70 |
Verify RTSP session timeout for established session |
step 1. Initiate an outbound RTSP connection
step 2. Verify the connection is established
step 3. Verify RTP and RTCP packets from the WAN are forwarded to LAN
step 4. Send RTSP PAUSE message from LAN to WAN
step 5. Send keep-alive RTSP GET_PARAMETER messages from LAN to
WAN every rtspGetParameterInterval seconds until natRtspTimeout
seconds elapses
step 6. Send RTSP PLAY message from LAN to WAN
step 7. Verify RTP and RTCP packets from the WAN are forwarded to LAN
step 8. Send RTSP TEARDOWN and close TCP session from LAN client
References:
IETF RFC 2326 "Real Time Streaming Protocol (RTSP)"
https://tools.ietf.org/html/rfc2326
| Test |
Module |
Name |
Synopsis |
Verify a Multipath TCP connection can be opened |
apps.tcl |
cdrouter_mptcp_1 |
Verify a Multipath TCP connection can be opened |
step 1. Initiate MPTCP connection from LAN client to WAN server
step 2. Verify MPTCP connection is established
step 3. Verify MPTCP connection attributes on LAN client and
WAN server match
step 4. Close MPTCP connection
References:
IETF RFC 8684 "TCP Extensions for Multipath Operation with Multiple Addresses"
https://tools.ietf.org/html/rfc8684
| Test |
Module |
Name |
Synopsis |
Verify a Multipath TCP connection with two subflows can be opened |
apps.tcl |
cdrouter_mptcp_2 |
Verify a Multipath TCP connection with two subflows can be opened |
step 1. Initiate MPTCP connection from LAN client to WAN server
step 2. Verify MPTCP connection is established
step 3. Verify MPTCP connection attributes on LAN client and
WAN server match
step 4. Transmit data on MPTCP connection from LAN client
step 5. Verify data is received by WAN server
step 6. Initiate new MPTCP subflow on MPTCP connection from
step 1
step 7. Verify new MPTCP subflow is established
step 8. Verify MPTCP subflow attributes on LAN client and WAN
server match
step 9. Transmit data on MPTCP connection from LAN client
step 10. Verify data is received by WAN server
step 11. Close MPTCP connection
References:
IETF RFC 8684 "TCP Extensions for Multipath Operation with Multiple Addresses"
https://tools.ietf.org/html/rfc8684
ipsecpt.tcl
IPSEC based VPN pass through from the LAN to the WAN
| Test |
Module |
Name |
Synopsis |
Verify IKE packets pass through router on UDP port 500 |
ipsecpt.tcl |
cdrouter_ipsecpt_1 |
Verify IKE packets pass through router on UDP port 500 |
step 1. Forward an IPSEC IKE packet from LAN to WAN
step 2. Verify packets are passed in both directions
| Test |
Module |
Name |
Synopsis |
Verify tunnel mode IPSEC packets pass through router |
ipsecpt.tcl |
cdrouter_ipsecpt_2 |
Verify tunnel mode IPSEC packets pass through router |
step 1. Forward an IPSEC packet from LAN to WAN
Note: Tunnel mode IPSEC packets are sent as IPv4 protocol 50
step 2. Verify the packet is received on the WAN
step 3. Send a tunnel mode IPSEC packet from the WAN side to LAN
step 4. Verify the packet is received on the LAN
Note: The testvar alwaysUseIke can be used to initiate an IKE connection
prior to sending tunnel mode IPSEC packets.
| Test |
Module |
Name |
Synopsis |
Fragmented tunnel mode IPSEC packets are forwarded between LAN and WAN |
ipsecpt.tcl |
cdrouter_ipsecpt_3 |
Fragmented tunnel mode IPSEC packets are forwarded between LAN and WAN |
step 1. Forward a fragmented IPSEC packet from LAN to WAN
Note: Tunnel mode IPSEC packets are sent as IPv4 protocol 50
step 2. Verify all IPv4 fragments are received on the WAN
step 3. Send an IPSEC packet from the WAN side to the router's public IPv4 address
step 4. Verify all IPv4 fragments are received on the LAN
NOTE: If the wanMode for this test is PPPoE, the MTU on both stacks is set
to 1492. Otherwise, the MTU is set to 1500. The test tries to send
1500 bytes of IPv4 data to resemble an IPSEC tunnel with a 1500 byte
payload.
Note: The testvar alwaysUseIke can be used to initiate an IKE connection
prior to sending tunnel mode IPSEC packets.
| Test |
Module |
Name |
Synopsis |
Verify unknown IPv4 protocol types using the pass through mechanism |
ipsecpt.tcl |
cdrouter_ipsecpt_30 |
Verify unknown IPv4 protocol types using the pass through mechanism |
step 1. Forward an IPv4 packet with protocol 52
step 2. Check for packet on WAN side of router
step 3. Forward the IPv4 protocol packet back to router's public IPv4 address
step 4. By default, the packet should not be received on the LAN
step 5. If the testvar 'unknownPassthrough' is set to yes, the packet should
be received on the LAN
By default, this test verifies that unknown IPv4 protocol packets are
forwarded by the router. However, if the router does not handle pass
through packets for all IPv4 protocol types, the testvar
'unknownPassthrough' should be set to 'no'. It defaults to 'yes'
| Test |
Module |
Name |
Synopsis |
Verify the maximum number of IPSEC pass through connections for a single LAN host |
ipsecpt.tcl |
cdrouter_ipsecpt_100 |
Verify the maximum number of IPSEC pass through connections for a single LAN host |
step 1. Forward a tunnel mode IPSEC packet from LAN to unique WAN IPv4 address
Note: Tunnel mode IPSEC packets are sent as IPv4 protocol 50
step 2. Verify the packet is received on the WAN
step 3. Send a tunnel mode IPSEC packet from the WAN side to LAN
step 4. Verify the packet is received on the LAN
step 5. Repeat up to the ipsecMaxTunnels value
Note: Each IPSEC tunnel uses a unique IPv4 destination address.
Note: The testvar alwaysUseIke can be used to initiate an IKE connection
prior to sending tunnel mode IPSEC packets.
| Test |
Module |
Name |
Synopsis |
Verify IPSEC pass through with multiple LAN clients using same VPN server |
ipsecpt.tcl |
cdrouter_ipsecpt_110 |
Verify IPSEC pass through with multiple LAN clients using same VPN server |
step 1. Start new DHCP client on the LAN interface
step 2. Forward an IPSEC packet from host 1 to VPN server on WAN
step 3. Forward an IPSEC packet from host 2 to VPN server on WAN
step 4. Verify both packets are received by the VPN server
step 5. Send a return IPSEC packet to each LAN host using unique SPI
step 6. Verify each LAN host receives IPSEC packet with correct SPI
Note: Each LAN client sends a IPSEC packet to the same VPN server
using unique SPI values in the ESP header. IPSEC packets
sent back from the WAN use the SPI value.
Note: This test is only supported by routers using SPI tracking
features to build NAPT mappings for return IPSEC/ESP traffic.
There is no reliable technique for a router to know the return
SPI value. However, some routers attempt to serialize the
return connections and associate incoming SPIs with outgoing
connections. While this does not work if packets are
reordered or lost, some routers do use this technique to allow
multiple LAN clients to use the same VPN server.
Note: The testvar alwaysUseIke can be used to initiate an IKE connection
prior to sending tunnel mode IPSEC packets.
| Test |
Module |
Name |
Synopsis |
Verify IKE with multiple LAN clients using same VPN server |
ipsecpt.tcl |
cdrouter_ipsecpt_120 |
Verify IKE with multiple LAN clients using same VPN server |
step 1. Start new DHCP client on the LAN interface
step 2. Forward an IPSEC IKE packet from host1 to VPN server on WAN
step 3. Forward an IPSEC IKE packet from host2 to VPN server on WAN
step 4. Verify both packets are received by the VPN server
step 5. Send return IKE/ISAKMP packets to LAN clients
step 6. Verify each LAN client receives correct IKE packet
Note: Each LAN client uses a unique ISAKMP cookie for the initiator and
responder cookies. There are two common techniques used to multiplex
multiple IKE connections all originating from port 500. Some routers will
change the IKE source port to another UDP port. This solution does not work
for all VPN servers which may not accept IKE traffic if the UDP source port
is not 500. Other routers will track the initiator and responder cookies in
the ISAKMP messages in order to demultiplex incoming IKE packets. This test
will succeed if either technique is used.
| Test |
Module |
Name |
Synopsis |
IPSEC pass through without NAT-T based IPSEC client |
ipsecpt.tcl |
cdrouter_ipsecpt_200 |
IPSEC pass through without NAT-T based IPSEC client |
step 1. Create new IPSEC VPN server on the WAN
step 2. Start the CDRouter IKE client on the LAN without using NAT-T
step 3. Verify IPSEC pass through allows IKE session to establish
step 4. Verify data traffic over the IPSEC tunnel
| Test |
Module |
Name |
Synopsis |
IPSEC pass through with NAT-T based IPSEC client |
ipsecpt.tcl |
cdrouter_ipsecpt_210 |
IPSEC pass through with NAT-T based IPSEC client |
step 1. Create new IPSEC VPN server on the WAN
step 2. Start the CDRouter IKE client on the LAN using NAT-T
step 3. Verify IPSEC pass through allows IKE session to establish
step 4. Verify data traffic over the IPSEC tunnel
forward.tcl
Forwarding tests with different packet sizes and directions
| Test |
Module |
Name |
Synopsis |
Verify IPv4 TTL is decremented for forwarded packets |
forward.tcl |
cdrouter_forward_1 |
Verify IPv4 TTL is decremented for forwarded packets |
step 1. Forward an IP packet from a LAN client to the WAN
step 2. Verify the TTL of the packet is decremented by 1
| Test |
Module |
Name |
Synopsis |
Verify packet is not forwarded when IPv4 TTL is 1 |
forward.tcl |
cdrouter_forward_2 |
Verify packet is not forwarded when IPv4 TTL is 1 |
step 1. Set the IP TTL of outbound packets to 1
step 2. Forward an IP packet from a LAN client to the WAN
step 3. Verify the packet is not forwarded
| Test |
Module |
Name |
Synopsis |
Verify packet can be forwarded back through incoming LAN interface |
forward.tcl |
cdrouter_forward_3 |
Verify packet can be forwarded back through incoming LAN interface |
step 1. Forward an IP packet from a LAN client to another LAN client
step 2. Forward packet using router's MAC address
step 3. Verify packet is forwarded back out the LAN interface
NOTE: The router may send an ICMP Redirect back to the originator.
| Test |
Module |
Name |
Synopsis |
Verify packet is not forwarded if IPv4 checksum is corrupt |
forward.tcl |
cdrouter_forward_4 |
Verify packet is not forwarded if IPv4 checksum is corrupt |
step 1. Configure the LAN host to send corrupt IPv4 checksums
step 2. Forward an IP packet from a LAN client to the WAN
step 3. Verify the packet is not forwarded
step 4. If the packet is forwarded, see if the checksum is valid
References:
IETF RFC 1812 "Requirements for IP Version 4 Routers" Section 4.2.2.5: Header Checksum: RFC 791 Section 3.1
As stated in Section [5.2.2], a router MUST verify the IP checksum of any
packet that is received, and MUST discard messages containing invalid
checksums. The router MUST NOT provide a means to disable this checksum
verification.
https://tools.ietf.org/html/rfc1812#section-4.2.2.5
| Test |
Module |
Name |
Synopsis |
Forward UDP packets with various packet lengths (LAN to WAN) |
forward.tcl |
cdrouter_forward_10 |
Forward UDP packets with various packet lengths (LAN to WAN) |
step 1. Initiate an outbound UDP connection with UDP data length of 4
step 2. Verify packets are received on the WAN interface
step 3. If wanMode is PPPoE,
continue forwarding until UDP data length is 1464 (1492 max IP len)
else if wanMode is PPTP or L2TP
continue forwarding until UDP data length is 1432 (1460 max IP len)
else for DHCP and static wanModes
continue forwarding until UDP data length is 1472 (1500 max IP len)
NOTE: Some routers will stop forwarding IP traffic while they renew their
WAN side IP address. This can cause this test to fail.
NOTE: Some routers allow static configuration of the MTU size. This may
default to 1492 even for routers running DHCP on the WAN side.
NOTE: This test will stop if the number of max failures is reached. This
value may be configured using testvar forwardingMaxFailures. Setting this
value to 0 will test each packet size regardles of the result.
testvar forwardingMaxFailures 20
| Test |
Module |
Name |
Synopsis |
Forward UDP packets with various packet lengths (WAN to LAN) |
forward.tcl |
cdrouter_forward_11 |
Forward UDP packets with various packet lengths (WAN to LAN) |
step 1. Initiate an outbound UDP connection with UDP data length of 4
step 2. Verify packet is received on the WAN interface
step 3. Forward a return packet from the WAN to the LAN
step 4. Verify packets are received on the LAN interface
step 5. If wanMode is PPPoE,
continue forwarding until UDP data length is 1464 (1492 max IP len)
else if wanMode is PPTP
continue forwarding until UDP data length is 1432 (1460 max IP len)
else for DHCP and static wanModes
continue forwarding until UDP data length is 1472 (1500 max IP len)
NOTE: Some routers will stop forwarding IP traffic while they renew their
WAN side IP address. This can cause this test to fail.
NOTE: Some routers allow static configuration of the MTU size. This may
default to 1492 even for routers running DHCP on the WAN side.
NOTE: This test will stop if the number of max failures is reached. This
value may be configured using testvar forwardingMaxFailures. Setting this
value to 0 will test each packet size regardles of the result.
testvar forwardingMaxFailures 20
| Test |
Module |
Name |
Synopsis |
No packets are forwarded if WAN lease expires |
forward.tcl |
cdrouter_forward_20 |
No packets are forwarded if WAN lease expires |
step 1. Disable the DHCP server and any ICMP or ARP responses
step 2. Wait for the WAN lease to expire
step 3. Forward packets from LAN client to WAN destination
step 4. Verify the packets are not forwarded out the WAN interface
step 5. Enable DHCP, ICMP, and ARP
NOTE: ARP/ICMP responses are also disabled on the WAN interface for this
test. Some routers use ARP or ICMP to verify that the WAN is still
operational.
jumbo.tcl
Jumbo MTU forwarding tests with different packet sizes and directions
| Test |
Module |
Name |
Synopsis |
Verify IPv4 TTL is decremented for forwarded jumbo MTU packets |
jumbo.tcl |
cdrouter_jumbo_1 |
Verify IPv4 TTL is decremented for forwarded jumbo MTU packets |
step 1. Forward an IP packet from a LAN client to the WAN that utilizes the
maximum supported jumbo mtu of both interfaces
step 2. Verify the TTL of the packet is decremented by 1
NOTE: The maximum jumbo packet size is configured using the testvar
jumboMtu.
| Test |
Module |
Name |
Synopsis |
Verify jumbo MTU packet is not forwarded when IPv4 TTL is 1 |
jumbo.tcl |
cdrouter_jumbo_2 |
Verify jumbo MTU packet is not forwarded when IPv4 TTL is 1 |
step 1. Set the IP TTL of outbound packets to 1
step 2. Forward an IP packet from a LAN client to the WAN that utilizes the
maximum supported jumbo mtu of both interfaces
step 3. Verify the packet is not forwarded
NOTE: The maximum jumbo packet size is configured using the testvar
jumboMtu.
| Test |
Module |
Name |
Synopsis |
Verify jumbo MTU packet can be forwarded back through incoming LAN interface |
jumbo.tcl |
cdrouter_jumbo_3 |
Verify jumbo MTU packet can be forwarded back through incoming LAN interface |
step 1. Forward an IP packet from a LAN client to another LAN client that
utilizes the maximum supported jumbo mtu of both interfaces
step 2. Forward packet using router's MAC address
step 3. Verify packet is forwarded back out the LAN interface
NOTE: The router may send an ICMP Redirect back to the originator.
NOTE: The maximum jumbo packet size is configured using the testvar
jumboMtu.
| Test |
Module |
Name |
Synopsis |
Verify jumbo MTU packet is not forwarded if IPv4 checksum is corrupt |
jumbo.tcl |
cdrouter_jumbo_4 |
Verify jumbo MTU packet is not forwarded if IPv4 checksum is corrupt |
step 1. Configure the LAN host to send corrupt IPv4 checksums
step 2. Forward an IP packet from a LAN client to the WAN that utilizes the
maximum supported jumbo mtu of both interfaces
step 3. Verify the packet is not forwarded
step 4. If the packet is forwarded, see if the checksum is valid
NOTE: The maximum jumbo packet size is configured using the testvar
jumboMtu.
References:
IETF RFC 1812 "Requirements for IP Version 4 Routers" Section 4.2.2.5: Header Checksum: RFC 791 Section 3.1
As stated in Section [5.2.2], a router MUST verify the IP checksum of any
packet that is received, and MUST discard messages containing invalid
checksums. The router MUST NOT provide a means to disable this checksum
verification.
https://tools.ietf.org/html/rfc1812#section-4.2.2.5
| Test |
Module |
Name |
Synopsis |
Forward jumbo MTU UDP packets with various packet lengths (LAN to WAN) |
jumbo.tcl |
cdrouter_jumbo_10 |
Forward jumbo MTU UDP packets with various packet lengths (LAN to WAN) |
step 1. Initiate an outbound UDP connection with UDP packet that utilizes
the maximum supported standard mtu of both interfaces
step 2. Verify packets are received on the WAN interface
step 3. Continue forwarding until the UDP packet utilizes the maximum
supported jumbo mtu of both interfaces
NOTE: Some routers will stop forwarding IP traffic while they renew their
WAN side IP address. This can cause this test to fail.
NOTE: The maximum jumbo packet size is configured using the testvar
jumboMtu.
NOTE: This test will stop if the number of max failures is reached. This
value may be configured using testvar forwardingMaxFailures. Setting this
value to 0 will test each packet size regardles of the result.
testvar forwardingMaxFailures 20
| Test |
Module |
Name |
Synopsis |
Forward jumbo MTU UDP packets with various packet lengths (WAN to LAN) |
jumbo.tcl |
cdrouter_jumbo_11 |
Forward jumbo MTU UDP packets with various packet lengths (WAN to LAN) |
step 1. Initiate an outbound UDP connection with UDP packet that utilizes
the maximum supported standard mtu of both interfaces
step 2. Verify packet is received on the WAN interface
step 3. Forward a return packet from the WAN to the LAN that utilizes the
maximum supported standard mtu of both interfaces
step 4. Verify packets are received on the LAN interface
step 5. Continue forwarding until the UDP packet utilizes the maximum
supported jumbo mtu of both interfaces
NOTE: Some routers will stop forwarding IP traffic while they renew
their WAN side IP address. This can cause this test to fail.
NOTE: The maximum jumbo packet size is configured using the testvar
jumboMtu.
NOTE: This test will stop if the number of max failures is reached. This
value may be configured using testvar forwardingMaxFailures. Setting this
value to 0 will test each packet size regardles of the result.
testvar forwardingMaxFailures 20
rip.tcl
RIPv1/v2 tests for LAN side of the router
| Test |
Module |
Name |
Synopsis |
Verify router sends RIPv1/v2 update on LAN side |
rip.tcl |
cdrouter_rip_1 |
Verify router sends RIPv1/v2 update on LAN side |
step 1. Listen for RIP reply from LAN side IP address of router
step 2. Verify RIP version
step 3. Verify source address of RIP reply
NOTE: This test is only run if the 'ripSupported' configuration is
set to 'yes'. The RIP version used for the test can be configured
using the 'ripVersion' variable in your configuration file.
References:
IETF RFC 1058 "Routing Information Protocol"
https://tools.ietf.org/html/rfc1058
IETF RFC 2453 "RIP Version 2"
https://tools.ietf.org/html/rfc2453
| Test |
Module |
Name |
Synopsis |
Verify router learns new RIP routes from LAN side RIP router (v1 or v2) |
rip.tcl |
cdrouter_rip_2 |
Verify router learns new RIP routes from LAN side RIP router (v1 or v2) |
step 1. Start new DHCP client on LAN interface
step 2. Announce new RIPv1/v2 route with metric 1 from new DHCP client
step 3. Forward from original LAN client to IP address within the
new RIPv1/v2 route range
step 4. Verify the packet is forwarded to the new DHCP client
References:
IETF RFC 1058 "Routing Information Protocol"
https://tools.ietf.org/html/rfc1058
IETF RFC 2453 "RIP Version 2"
https://tools.ietf.org/html/rfc2453
| Test |
Module |
Name |
Synopsis |
Verify router responds to RIP requests on LAN interface |
rip.tcl |
cdrouter_rip_5 |
Verify router responds to RIP requests on LAN interface |
step 1. Send RIP Request from new UDP src port to RIP destination address
step 2. Verify router returns a RIP response
step 3. Verify the response is sent to the correct UDP port
step 4. Verify the response is sent using unicast IP destination
References:
IETF RFC 1058 "Routing Information Protocol"
https://tools.ietf.org/html/rfc1058
IETF RFC 2453 "RIP Version 2"
https://tools.ietf.org/html/rfc2453
| Test |
Module |
Name |
Synopsis |
Verify router selects RIP route with lowest metric (v1 or v2) |
rip.tcl |
cdrouter_rip_10 |
Verify router selects RIP route with lowest metric (v1 or v2) |
step 1. Start 2 new DHCP clienst on LAN interface (R1 and R2)
step 2. Announce new RIPv1/v2 route with metric 10 from R1
step 3. Announce same RIPv1/v2 route with metric 9 from R2
step 5. Forward from original LAN client to IP address within the
new RIPv1/v2 route range
step 6. Verify the packet is forwarded to R2
References:
IETF RFC 1058 "Routing Information Protocol"
https://tools.ietf.org/html/rfc1058
IETF RFC 2453 "RIP Version 2"
https://tools.ietf.org/html/rfc2453
| Test |
Module |
Name |
Synopsis |
Verify router ignores routes with a metric of 16 |
rip.tcl |
cdrouter_rip_12 |
Verify router ignores routes with a metric of 16 |
step 1. Start new DHCP client on LAN interface
step 2. Announce new RIPv1/v2 route with metric 16 from new DHCP client
step 3. Forward from original LAN client to IP address within the
new RIPv1/v2 route range
step 4. Verify the packet is not forwarded to the new DHCP client
step 5. Verify the packet is forwarded to WAN side
References:
IETF RFC 1058 "Routing Information Protocol"
https://tools.ietf.org/html/rfc1058
IETF RFC 2453 "RIP Version 2"
https://tools.ietf.org/html/rfc2453
| Test |
Module |
Name |
Synopsis |
Verify router uses split horizon or poison reverse for learned RIP routes |
rip.tcl |
cdrouter_rip_20 |
Verify router uses split horizon or poison reverse for learned RIP routes |
step 1. Start new DHCP client on LAN interface
step 2. Announce new RIPv1/v2 route with metric 1 from new DHCP client
step 3. Wait for new RIP update
step 4. Verify route is not announced (split horizon) or announced as
unreachable (poison reverse)
References:
IETF RFC 1058 "Routing Information Protocol"
https://tools.ietf.org/html/rfc1058
IETF RFC 2453 "RIP Version 2"
https://tools.ietf.org/html/rfc2453
| Test |
Module |
Name |
Synopsis |
Verify router announces default route on LAN side |
rip.tcl |
cdrouter_rip_30 |
Verify router announces default route on LAN side |
step 1. Listen for RIP updates for 1 minute
step 2. Verify default route (0.0.0.0) is announced as reachable
References:
IETF RFC 1058 "Routing Information Protocol"
https://tools.ietf.org/html/rfc1058
IETF RFC 2453 "RIP Version 2"
https://tools.ietf.org/html/rfc2453
| Test |
Module |
Name |
Synopsis |
Verify the maximum number of RIP routes supported |
rip.tcl |
cdrouter_rip_100 |
Verify the maximum number of RIP routes supported |
step 1. Start a new DHCP client on LAN interface
step 2. Announce new RIPv1/v2 routes with metric 1 from new DHCP client
NOTE: The 'ripMaxRoutes' variable in your configuration file
determines the number of RIPv1/v2 routes that are announced.
step 3. Forward from original LAN client to IP address within the
each new route range
step 4. Verify packets are forwarded for each new route
References:
IETF RFC 1058 "Routing Information Protocol"
https://tools.ietf.org/html/rfc1058
IETF RFC 2453 "RIP Version 2"
https://tools.ietf.org/html/rfc2453
| Test |
Module |
Name |
Synopsis |
Verify router learns new RIP routes from WAN side RIP router (v1 or v2) |
rip.tcl |
cdrouter_rip_200 |
Verify router learns new RIP routes from WAN side RIP router (v1 or v2) |
step 1. Announce new RIPv1/v2 route with metric 1 from WAN side
step 2. Wait for new RIP update on the LAN
step 3. Verify new route is announced on the LAN
step 4. Forward packet from LAN to new IP destination
step 5. Verify packet is forwarded to WAN side
NOTE: This test is only enabled when testvar ripAcceptWanUpdate
is set to yes. The default is no.
testvar ripAcceptWanUpdate yes
References:
IETF RFC 1058 "Routing Information Protocol"
https://tools.ietf.org/html/rfc1058
IETF RFC 2453 "RIP Version 2"
https://tools.ietf.org/html/rfc2453
scaling.tcl
Scaling tests for maximum number of DHCP clients and connections (TCP, HTTP, VPN)
| Test |
Module |
Name |
Synopsis |
Verify all DHCP clients are operational |
scaling.tcl |
cdrouter_scale_1 |
Verify all DHCP clients are operational |
step 1. Determine the size of the IPv4 LAN address pool
step 2. Create a DHCP client for each available IP address
step 3. Verify each client obtains an IP address within the range
step 4. Verify there are no address conflicts
step 5. Verify each client can establish an outbound HTTP connection to the
remote host on the WAN
step 6. Verify each client can send/receive data over the HTTP connection
step 7. Close each TCP connection
step 8. Release all new DHCP client leases
NOTE: The DHCP address pool size is set in your configuration file using
the 'dhcpClientStart' and 'dhcpClientEnd' testvars. These values must
match the values set on the DUT. The pool size used in the test may be
reduced if the testvar 'ipv4MaxLanClients' is defined with a value in your
configuration.
One of the addresses remains in use through the test run for a host on the
LAN side. This test will attempt to create clients for the pool size - 1.
If you are using multiple LAN interfaces, the number of DHCP clients from
each interface will also be subtracted from the DHCP pool size.
NOTE: All DHCP clients created during this test will use unique MAC
addresses that do not conflict with any DHCP reservations that may be
defined. This test will also verify that all clients receive valid DHCP
addresses from the dynamic pool. A failure will be generated if any client
receives an invalid address from the DHCP server. Invalid addresses are
defined as:
* Addresses outside of the configured DHCP pool range
* Excluded addresses defined by the 'dhcpClientExclude' testvar
* Reserved addresses defined by the 'dhcpClientReservedIp[x]' and
'dhcpClientReservedMac[x]' testvars
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol"
https://tools.ietf.org/html/rfc2131
| Test |
Module |
Name |
Synopsis |
Verify all DHCP clients with multiple TCP connections |
scaling.tcl |
cdrouter_scale_2 |
Verify all DHCP clients with multiple TCP connections |
step 1. Determine the size of the IPv4 LAN address pool
step 2. Determine the maximum number of TCP connections to create for
each DHCP client
step 3. Create a DHCP client for each available IP address
step 4. Verify each client obtains an IP address within the range
step 5. Verify there are no address conflicts
step 6. Verify each client can establish scaleTcpConnsPerHost outbound
HTTP connections to port 80; each connection is to a unique IP
address unless the free network range has been exceeded
step 7. Verify each client can send/receive data over each connection
step 8. Close each TCP connection
step 9. Release all new DHCP client leases
NOTE: The DHCP address pool size is set in your configuration file using
the 'dhcpClientStart' and 'dhcpClientEnd' testvars. These values must
match the values set on the DUT. The pool size used in the test may be
reduced if the testvar 'ipv4MaxLanClients' is defined with a value in your
configuration.
One of the addresses remains in use through the test run for a host on the
LAN side. This test will attempt to create clients for the pool size - 1.
If you are using multiple LAN interfaces, the number of DHCP clients from
each interface will also be subtracted from the DHCP pool size.
NOTE: The maximum number of TCP connections per host is set in your
configuration file using the testvar 'scaleTcpConnsPerHost'. If this entry
is not included in your configuration file, it defaults to 5.
NOTE: All DHCP clients created during this test will use unique MAC
addresses that do not conflict with any DHCP reservations that may be
defined. This test will also verify that all clients receive valid DHCP
addresses from the dynamic pool. A failure will be generated if any client
receives an invalid address from the DHCP server. Invalid addresses are
defined as:
* Addresses outside of the configured DHCP pool range
* Excluded addresses defined by the 'dhcpClientExclude' testvar
* Reserved addresses defined by the 'dhcpClientReservedIp[x]' and
'dhcpClientReservedMac[x]' testvars
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol"
https://tools.ietf.org/html/rfc2131
| Test |
Module |
Name |
Synopsis |
Verify all DHCP clients with single UDP connection |
scaling.tcl |
cdrouter_scale_3 |
Verify all DHCP clients with single UDP connection |
step 1. Determine the size of the IPv4 LAN address pool
step 2. Determine the maximum number of UDP connections to create for
each DHCP client
step 3. Create a DHCP client for each available IP address within the pool
step 4. Verify each client obtains an IP address within the range
step 5. Verify there are no address conflicts
step 6. Verify each client can establish one outbound UDP connection
step 7. Verify each client can send/receive data over each connection
step 8. Release all new DHCP client leases
NOTE: The DHCP address pool size is set in your configuration file using
the 'dhcpClientStart' and 'dhcpClientEnd' testvars. These values must
match the values set on the DUT. The pool size used in the test may be
reduced if the testvar 'ipv4MaxLanClients' is defined with a value in your
configuration.
One of the addresses remains in use through the test run for a host on the
LAN side. This test will attempt to create clients for the pool size - 1.
If you are using multiple LAN interfaces, the number of DHCP clients from
each interface will also be subtracted from the DHCP pool size.
NOTE: All DHCP clients created during this test will use unique MAC
addresses that do not conflict with any DHCP reservations that may be
defined. This test will also verify that all clients receive valid DHCP
addresses from the dynamic pool. A failure will be generated if any client
receives an invalid address from the DHCP server. Invalid addresses are
defined as:
* Addresses outside of the configured DHCP pool range
* Excluded addresses defined by the 'dhcpClientExclude' testvar
* Reserved addresses defined by the 'dhcpClientReservedIp[x]' and
'dhcpClientReservedMac[x]' testvars
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol"
https://tools.ietf.org/html/rfc2131
| Test |
Module |
Name |
Synopsis |
Verify no duplicate IP addresses are assigned when DHCP address pool is exhausted |
scaling.tcl |
cdrouter_scale_10 |
Verify no duplicate IP addresses are assigned when DHCP address pool is exhausted |
step 1. Determine the size of the IPv4 LAN address pool
step 2. Create a DHCP client for each available IP address
step 3. Verify each client obtains an IP address within the range
step 4. Verify there are no address conflicts
step 5. Attempt to create one additional DHCP client
step 6. Verify that the DHCP client in step 5 does not obtain an IP address
step 7. Release all DHCP client leases
NOTE: The DHCP address pool size is set in your configuration file using
the 'dhcpClientStart' and 'dhcpClientEnd' testvars. One of the addresses
remains in use through the test run for a host on the LAN side. This test
will attempt to create clients for the pool size - 1. If you are using
multiple LAN interfaces, the number of DHCP clients from each interface
will also be subtracted from the DHCP pool size.
NOTE: All DHCP clients created during this test will use unique MAC
addresses that do not conflict with any DHCP reservations that may be
defined. This test will also verify that all clients receive valid DHCP
addresses from the dynamic pool. A failure will be generated if any client
receives an invalid address from the DHCP server. Invalid addresses are
defined as:
* Addresses outside of the configured DHCP pool range
* Excluded addresses defined by the 'dhcpClientExclude' testvar
* Reserved addresses defined by the 'dhcpClientReservedIp[x]' and
'dhcpClientReservedMac[x]' testvars
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol"
https://tools.ietf.org/html/rfc2131
| Test |
Module |
Name |
Synopsis |
Verify all DHCP clients can create an IPSEC tunnel |
scaling.tcl |
cdrouter_scale_15 |
Verify all DHCP clients can create an IPSEC tunnel |
step 1. Determine the number of IPSEC tunnels to create based on the value
of the ipsecMaxTunnels testvar
step 2. Create one DHCP client per IPSEC tunnel
step 3. Verify the client obtains an IP address within the range
step 4. Verify there are no address conflicts
step53. Verify each client can establish an outbound IPSEC tunnel to a
unique IP destination address on the WAN side
step 6. Verify IKE session is established
step 7. Verify IPSEC/ESP packets pass through
step 8. Release all new DHCP client leases
NOTE: This test is only supported by routers using SPI tracking
features to build NAPT mappings for return IPSEC/ESP traffic.
There is no reliable technique for a router to know the return
SPI value. However, some routers attempt to serialize the
return connections and associate incoming SPIs with outgoing
connections. While this does not work if packets are
reordered or lost, some routers do use this technique to allow
multiple LAN clients to use the same VPN server.
NOTE: The DHCP address pool size is set in your configuration file using
the 'dhcpClientStart' and 'dhcpClientEnd' testvars. These values must
match the values set on the DUT. The pool size used in the test may be
reduced if the testvar 'ipv4MaxLanClients' is defined with a value in your
configuration.
NOTE: If the maximum number of IPSEC tunnels supported is less than
the DHCP address pool size, not all DHCP clients will be used. The
maximum number of IPSEC tunnels is configured using the
'ipsecMaxTunnels' testvar.
NOTE: All DHCP clients created during this test will use unique MAC
addresses that do not conflict with any DHCP reservations that may be
defined. This test will also verify that all clients receive valid DHCP
addresses from the dynamic pool. A failure will be generated if any client
receives an invalid address from the DHCP server. Invalid addresses are
defined as:
* Addresses outside of the configured DHCP pool range
* Excluded addresses defined by the 'dhcpClientExclude' testvar
* Reserved addresses defined by the 'dhcpClientReservedIp[x]' and
'dhcpClientReservedMac[x]' testvars
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol"
https://tools.ietf.org/html/rfc2131
| Test |
Module |
Name |
Synopsis |
Verify all DHCP clients can create a PPTP tunnel |
scaling.tcl |
cdrouter_scale_20 |
Verify all DHCP clients can create a PPTP tunnel |
step 1. Determine the number of PPTP tunnels to create based on the value
of the pptpMaxTunnels testvar
step 2. Create one DHCP client per PPTP tunnel
step 3. Verify the client obtains an IP address within the range
step 4. Verify there are no address conflicts
step 5. Verify each client can establish an outbound PPTP tunnel
to a unique IP destination address on the WAN side
step 6. Release all new DHCP client leases
NOTE: The DHCP address pool size is set in your configuration file using
the 'dhcpClientStart' and 'dhcpClientEnd' testvars. These values must
match the values set on the DUT. The pool size used in the test may be
reduced if the testvar 'ipv4MaxLanClients' is defined with a value in your
configuration.
NOTE: If the maximum number of PPTP tunnels supported is less than
the DHCP address pool size, not all DHCP clients will be used. The
maximum number of PPTP tunnels is configured using the
pptpMaxTunnels variable.
NOTE: All DHCP clients created during this test will use unique MAC
addresses that do not conflict with any DHCP reservations that may be
defined. This test will also verify that all clients receive valid DHCP
addresses from the dynamic pool. A failure will be generated if any client
receives an invalid address from the DHCP server. Invalid addresses are
defined as:
* Addresses outside of the configured DHCP pool range
* Excluded addresses defined by the 'dhcpClientExclude' testvar
* Reserved addresses defined by the 'dhcpClientReservedIp[x]' and
'dhcpClientReservedMac[x]' testvars
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol"
https://tools.ietf.org/html/rfc2131
| Test |
Module |
Name |
Synopsis |
Verify all DHCP clients can create a L2TP/IPSEC tunnel |
scaling.tcl |
cdrouter_scale_30 |
Verify all DHCP clients can create a L2TP/IPSEC tunnel |
step 1. Determine the number of L2TP tunnels to create based on the value
of the l2tpMaxTunnels testvar
step 2. Create one DHCP client per L2TP tunnel
step 3. Verify the client obtains an IP address within the range
step 4. Verify there are no address conflicts
step 5. Verify each client can establish an outbound L2TP/IPSEC tunnel
to a unique IP destination address on the WAN side
step 6. Release all new DHCP client leases
NOTE: The DHCP address pool size is set in your configuration file using
the 'dhcpClientStart' and 'dhcpClientEnd' testvars. These values must
match the values set on the DUT. The pool size used in the test may be
reduced if the testvar 'ipv4MaxLanClients' is defined with a value in your
configuration.
NOTE: If the maximum number of L2TP tunnels supported is less than
the DHCP address pool size, not all DHCP clients will be used. The
maximum number of L2TP tunnels is configured using the
l2tpMaxTunnels variable.
NOTE: All DHCP clients created during this test will use unique MAC
addresses that do not conflict with any DHCP reservations that may be
defined. This test will also verify that all clients receive valid DHCP
addresses from the dynamic pool. A failure will be generated if any client
receives an invalid address from the DHCP server. Invalid addresses are
defined as:
* Addresses outside of the configured DHCP pool range
* Excluded addresses defined by the 'dhcpClientExclude' testvar
* Reserved addresses defined by the 'dhcpClientReservedIp[x]' and
'dhcpClientReservedMac[x]' testvars
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol"
https://tools.ietf.org/html/rfc2131
| Test |
Module |
Name |
Synopsis |
Verify all DHCP clients can create a L2TP/IPSEC tunnel with NAT-T |
scaling.tcl |
cdrouter_scale_40 |
Verify all DHCP clients can create a L2TP/IPSEC tunnel with NAT-T |
step 1. Determine the number of L2TP tunnels to create based on the value
of the l2tpMaxTunnels testvar
step 2. Create one DHCP client per L2TP tunnel
step 3. Verify the client obtains an IP address within the range
step 4. Verify there are no address conflicts
step 5. Verify each client can establish an outbound L2TP/IPSEC tunnel
to a unique IP destination address on the WAN side using NAT-T
step 6. Release all new DHCP client leases
NOTE: The DHCP address pool size is set in your configuration file using
the 'dhcpClientStart' and 'dhcpClientEnd' testvars. These values must
match the values set on the DUT. The pool size used in the test may be
reduced if the testvar 'ipv4MaxLanClients' is defined with a value in your
configuration.
NOTE: If the maximum number of L2TP tunnels supported is less than
the DHCP address pool size, not all DHCP clients will be used. The
maximum number of L2TP tunnels is configured using the
l2tpMaxTunnels variable.
NOTE: All DHCP clients created during this test will use unique MAC
addresses that do not conflict with any DHCP reservations that may be
defined. This test will also verify that all clients receive valid DHCP
addresses from the dynamic pool. A failure will be generated if any client
receives an invalid address from the DHCP server. Invalid addresses are
defined as:
* Addresses outside of the configured DHCP pool range
* Excluded addresses defined by the 'dhcpClientExclude' testvar
* Reserved addresses defined by the 'dhcpClientReservedIp[x]' and
'dhcpClientReservedMac[x]' testvars
References:
IETF RFC 2131 "Dynamic Host Configuration Protocol"
https://tools.ietf.org/html/rfc2131
vservice.tcl
Port forwarding tests to verify configured virtual services on the router
| Test |
Module |
Name |
Synopsis |
Verify each configured TCP virtual service |
vservice.tcl |
cdrouter_vservice_10 |
Verify each configured TCP virtual service |
step 1. Read all the configured virtual services for TCP
step 2. For each service, initiate a TCP connection from the WAN
to the router's WAN side IP address and specified TCP port
step 3. Verify the TCP session is established
step 4. Verify the TCP session is forwarded to the correct LAN host
step 5. Close the TCP session
step 6. Repeat for each TCP service
NOTE: Up to 4096 virtual services can be configured in your configuration
file using the virtualTcpService* entries. For example,
testvar virtualTcpServicePort1 23
testvar virtualTcpServiceHost1 192.168.1.200
testvar virtualTcpServiceName1 telnet
testvar virtualTcpServiceLanPort1 23
testvar virtualTcpServicePort2 25
testvar virtualTcpServiceHost2 192.168.1.201
testvar virtualTcpServiceName2 smtp
testvar virtualTcpServiceLanPort2 25
The IP address on the LAN side for each virtual serivce must be on the
same network as the "lanIp" address. You may also configure a different
LAN port using the *LanPort* entries. By default, the LAN port for the
service is the same as the WAN and does not need to be configured.
NOTE: The expected IP source address of packets forwarded using the
virtual service can be configured using the testvar 'virtualWANTransType'.
This value can be set to "none", "public" or "private". When set to "none"
(default), no IP address translation should be done on the IP source
address of a packet incoming from the WAN to a configured virtual service.
When set to "public", the router should use the WAN side IP address as the
source address for all packets originating on the WAN that are forwarded
to a virtual services port. When set to "private", the router should use
the LAN side IP address as the source address for all packets originating
on the WAN that are forwarded to a virtual service port.
| Test |
Module |
Name |
Synopsis |
Verify each configured UDP virtual service |
vservice.tcl |
cdrouter_vservice_20 |
Verify each configured UDP virtual service |
step 1. Read all the configured virtual services for UDP
step 2. For each service, send a UDP packet from the WAN
to the router's WAN side IP address and specified UDP port
step 3. Verify the UDP packet is forwarded to the correct LAN host
step 4. Send a return UDP packet from the LAN host to the WAN originator
step 5. Verify the UDP packet is forwarded back to the WAN
step 6. Repeat for each UDP service
NOTE: Up to 4096 virtual services can be configured in your configuration
file using the virtualUdpService* entries. For example,
testvar virtualUdpServicePort1 23
testvar virtualUdpServiceHost1 192.168.1.200
testvar virtualUdpServiceName1 telnet
testvar virtualUdpServicePort2 25
testvar virtualUdpServiceHost2 192.168.1.201
testvar virtualUdpServiceName2 smtp
The IP address on the LAN side for each virtual serivce must be on the
same network as the "lanIp" address.
| Test |
Module |
Name |
Synopsis |
Verify TCP virtual services are reachable from the LAN side |
vservice.tcl |
cdrouter_vservice_30 |
Verify TCP virtual services are reachable from the LAN side |
step 1. Read all the configured virtual services for TCP
step 2. For each service, initiate a TCP connection from the LAN
to the router's WAN side IP address and specified TCP port
step 3. Verify the TCP session is established
step 4. Verify the TCP session is forwarded to the correct LAN host
step 5. Close the TCP session
step 6. Repeat for each TCP service
NOTE: Up to 4096 virtual services can be configured in your configuration
file using the virtualTcpService* entries. For example,
testvar virtualTcpServicePort1 23
testvar virtualTcpServiceHost1 192.168.1.200
testvar virtualTcpServiceName1 telnet
testvar virtualTcpServicePort2 25
testvar virtualTcpServiceHost2 192.168.1.201
testvar virtualTcpServiceName2 smtp
The IP address on the LAN side for each virtual serivce must be on the
same network as the "lanIp" address.
NOTE: The expected IP source address of packets forwarded using the
virtual service can be configured using the testvar 'virtualLANTransType'.
This value can be set to "public" or "private". When set to "public",
the router should use the WAN side IP address as the source address for
all packets originating on the LAN that are forwarded to a virtual services
port. When set to "private", the router should use the LAN side IP address
as the source address for all packets originating on the LAN that are
forwarded to a virtual service port.
| Test |
Module |
Name |
Synopsis |
Verify UDP virtual services are reachable from the LAN side |
vservice.tcl |
cdrouter_vservice_40 |
Verify UDP virtual services are reachable from the LAN side |
step 1. Read all the configured virtual services for UDP
step 2. For each service, send a UDP packet from the LAN
to the router's WAN side IP address and specified UDP port
step 3. Verify the UDP packet is forwarded to the correct LAN host
step 4. Send a return UDP packet from the LAN host to the LAN originator
step 5. Verify the UDP packet is forwarded back to the LAN
step 6. Repeat for each UDP service
NOTE: Up to 4096 virtual services can be configured in your configuration
file using the virtualUdpService* entries. For example,
testvar virtualUdpServicePort1 23
testvar virtualUdpServiceHost1 192.168.1.200
testvar virtualUdpServiceName1 telnet
testvar virtualUdpServicePort2 25
testvar virtualUdpServiceHost2 192.168.1.201
testvar virtualUdpServiceName2 smtp
The IP address on the LAN side for each virtual serivce must be on the
same network as the "lanIp" address.
NOTE: The expected IP source address of packets forwarded using the
virtual service can be configured using the testvar 'virtualLANTransType'.
This value can be set to "public" or "private". When set to "public",
the router should use the WAN side IP address as the source address for
all packets originating on the LAN that are forwarded to a virtual services
port. When set to "private", the router should use the LAN side IP address
as the source address for all packets originating on the LAN that are
forwarded to a virtual service port.
url-filter.tcl
URL filtering tests for LAN side HTTP clients
| Test |
Module |
Name |
Synopsis |
Verify HTTP GETs to filtered URLs are blocked |
url-filter.tcl |
cdrouter_urlfilter_10 |
Verify HTTP GETs to filtered URLs are blocked |
step 1. Set up new web server on WAN side using free network address
step 2. Resolve domain address using DNS from LAN client
step 3. Initiate TCP connection to web server from LAN client
step 4. Verify TCP connection is opened
step 5. Send HTTP GET from LAN client to new server for requested URL
step 6. URL is considered blocked if one of the following occurs:
a. The LAN client does not receive a page from the webserver
b. The LAN client receives a page from the webserver, but
the HTTP status code is not 200 "OK"
c. The LAN client receives a page from the webserver with
an HTTP status code of 200, but the returned page contains
text indicating that the page was administratively blocked,
as defined by the testvar 'urlFilterBlockedText'
step 7. Repeat for each configured filtered URL
step 8. Verify that each configured non-filtered URL returns a valid
webpage
NOTE: This test is only performed if the testvar 'urlFilterSupported'
is set to "yes". The testvars 'filtered-urls' and 'non-filtered-urls'
are used to specify which URLs are used during this test.
NOTE: This test allows the CPE to block a URL by preventing establishment
of the TCP connection in step 4, using a proxy to return a non-200 HTTP
status code in step 6, or using a proxy to return a 200 HTTP status code
in step 6 with alternate webpage text indicating that the page was
admninistratively blocked. The testvar 'urlFilterBlockedText' should be
configured with a portion of the expected text returned when a page is
blocked by the CPE.
| Test |
Module |
Name |
Synopsis |
Verify HTTP GETs to filtered URLs are blocked without DNS lookups |
url-filter.tcl |
cdrouter_urlfilter_12 |
Verify HTTP GETs to filtered URLs are blocked without DNS lookups |
step 1. Set up new web server on WAN side using free network address
step 2. Resolve only domain addresses for non-filtered URLs from LAN client
step 3. Initiate TCP connection to web server from LAN client
step 4. Verify TCP connection is opened
step 5. Send HTTP GET from LAN client to new server for requested URL
step 6. URL is considered blocked if one of the following occurs:
a. The LAN client does not receive a page from the webserver
b. The LAN client receives a page from the webserver, but
the HTTP status code is not 200 "OK"
c. The LAN client receives a page from the webserver with
an HTTP status code of 200, but the returned page contains
text indicating that the page was administratively blocked,
as defined by the testvar 'urlFilterBlockedText'
step 7. Repeat for each configured filtered URL
step 8. Verify that each configured non-filtered URL returns a valid
webpage
NOTE: This test is only performed if the testvar 'urlFilterSupported'
is set to "yes". The testvars 'filtered-urls' and 'non-filtered-urls'
are used to specify which URLs are used during this test.
NOTE: This test allows the CPE to block a URL by preventing establishment
of the TCP connection in step 4, using a proxy to return a non-200 HTTP
status code in step 6, or using a proxy to return a 200 HTTP status code
in step 6 with alternate webpage text indicating that the page was
admninistratively blocked. The testvar 'urlFilterBlockedText' should be
configured with a portion of the expected text returned when a page is
blocked by the CPE.
| Test |
Module |
Name |
Synopsis |
Verify HTTP HEADs to filtered URLs are blocked |
url-filter.tcl |
cdrouter_urlfilter_15 |
Verify HTTP HEADs to filtered URLs are blocked |
step 1. Set up new web server on WAN side using free network address
step 2. Resolve domain address using DNS from LAN client
step 3. Initiate TCP connection to web server from LAN client
step 4. Verify TCP connection is opened
step 5. Send HTTP HEAD from LAN client to new server for requested URL
step 6. URL is considered blocked if one of the following occurs:
a. The LAN client does not receive a page from the webserver
b. The LAN client receives a page from the webserver, but
the HTTP status code is not 200 "OK"
c. The LAN client receives a page from the webserver with
an HTTP status code of 200, but the returned page contains
text indicating that the page was administratively blocked,
as defined by the testvar 'urlFilterBlockedText'
step 7. Repeat for each configured filtered URL
step 8. Verify that each configured non-filtered URL returns a valid
webpage
NOTE: This test is only performed if the testvar 'urlFilterSupported'
is set to "yes". The testvars 'filtered-urls' and 'non-filtered-urls'
are used to specify which URLs are used during this test.
NOTE: This test allows the CPE to block a URL by preventing establishment
of the TCP connection in step 4, using a proxy to return a non-200 HTTP
status code in step 6, or using a proxy to return a 200 HTTP status code
in step 6 with alternate webpage text indicating that the page was
admninistratively blocked. The testvar 'urlFilterBlockedText' should be
configured with a portion of the expected text returned when a page is
blocked by the CPE.
| Test |
Module |
Name |
Synopsis |
Verify HTTP POSTs to filtered URLs are blocked |
url-filter.tcl |
cdrouter_urlfilter_20 |
Verify HTTP POSTs to filtered URLs are blocked |
step 1. Set up new web server on WAN side using free network address
step 2. Resolve domain address using DNS from LAN client
step 3. Initiate TCP connection to web server from LAN client
step 4. Verify TCP connection is opened
step 5. Send HTTP POST from LAN client to new server for requested URL
step 6. URL is considered blocked if one of the following occurs:
a. The LAN client does not receive a page from the webserver
b. The LAN client receives a page from the webserver, but
the HTTP status code is not 200 "OK"
c. The LAN client receives a page from the webserver with
an HTTP status code of 200, but the returned page contains
text indicating that the page was administratively blocked,
as defined by the testvar 'urlFilterBlockedText'
step 7. Repeat for each configured filtered URL
step 8. Verify that each configured non-filtered URL returns a valid
webpage
NOTE: This test is only performed if the testvar 'urlFilterSupported'
is set to "yes". The testvars 'filtered-urls' and 'non-filtered-urls'
are used to specify which URLs are used during this test.
NOTE: This test allows the CPE to block a URL by preventing establishment
of the TCP connection in step 4, using a proxy to return a non-200 HTTP
status code in step 6, or using a proxy to return a 200 HTTP status code
in step 6 with alternate webpage text indicating that the page was
admninistratively blocked. The testvar 'urlFilterBlockedText' should be
configured with a portion of the expected text returned when a page is
blocked by the CPE.
| Test |
Module |
Name |
Synopsis |
Verify URL filtering does not look at Cookie data |
url-filter.tcl |
cdrouter_urlfilter_30 |
Verify URL filtering does not look at Cookie data |
step 1. Set up new web server on WAN side using free network address
step 2. Resolve domain address using DNS from LAN client
step 3. Initiate TCP connection to web server from LAN client
step 4. Verify TCP connection is opened
step 5. Send HTTP GET from LAN client to new server for requested URL
step 6. Use one of the filtered URLs as the cookie data
step 7. Verify webserver does return a response
step 8. Repeat for each configured allowed URL
NOTE: This test is only performed if the testvar 'urlFilterSupported'
is set to "yes". The testvars 'filtered-urls' and 'non-filtered-urls'
are used to specify which URLs are used during this test.
| Test |
Module |
Name |
Synopsis |
Verify HTTPS GETs to filtered URLs are blocked |
url-filter.tcl |
cdrouter_urlfilter_40 |
Verify HTTPS GETs to filtered URLs are blocked |
step 1. Set up new HTTPS server on WAN side using free network address
step 2. Resolve domain address using DNS from LAN client
step 3. Initiate TCP connection to web server from LAN client
step 4. If TCP connection is not established, skip to step 9
step 5. Verify TCP connection is opened
step 6. Establish SSL connection to server
step 7. Send HTTPS GET from LAN client to new server for requested URL
step 8. URL is considered blocked if one of the following occurs:
a. The LAN client does not receive a page from the webserver
b. The LAN client receives a page from the webserver, but
the HTTP status code is not 200 "OK"
c. The LAN client receives a page from the webserver with
an HTTP status code of 200, but the returned page contains
text indicating that the page was administratively blocked,
as defined by the testvar 'urlFilterBlockedText'
step 9. Repeat for each configured filtered URL
step 10. Verify that each configured non-filtered URL returns a valid
webpage
NOTE: This test is only performed if the testvar 'urlFilterSupported'
is set to "yes". The testvars 'filtered-urls' and 'non-filtered-urls'
are used to specify which URLs are used during this test.
NOTE: This test allows the CPE to block a URL by preventing establishment
of the TCP connection in step 4, using a proxy to return a non-200 HTTP
status code in step 8, or using a proxy to return a 200 HTTP status code
in step 8 with alternate webpage text indicating that the page was
admninistratively blocked. The testvar 'urlFilterBlockedText' should be
configured with a portion of the expected text returned when a page is
blocked by the CPE.
triggerp.tcl
Tests to verify configured trigger ports on the router
| Test |
Module |
Name |
Synopsis |
Verify basic case for each configured trigger port application |
triggerp.tcl |
cdrouter_tport_10 |
Verify basic case for each configured trigger port application |
step 1. Read all the configured trigger ports
step 2. For each port, verify that none of the public triggered ports
are currently open on the WAN side.
step 3. Initiate a TCP or UDP session from the LAN to the WAN side
using the triggered port as the destination port.
step 4. Verify the TCP or UDP session is created
step 5. For each public port that should now be triggered, open
a connection from the WAN to the LAN using the public
port as the destination port and the router's nat IP address
as the destination IP address
step 5. Verify a connection can be estabished for each public port
step 6. Close down each public port
step 7. Close down the original LAN side connection used for the trigger
step 8. Repeat for each configured port trigger
NOTE: Up to 4096 trigger ports can be configured in your configuration
file. For example,
testvar triggerName1 net2phone-1
testvar triggerPort1 6801
testvar triggerType1 udp
testvar triggerPublic1 30000
testvar triggerPublicType1 both
testvar triggerName2 app1
testvar triggerPort2 20000
testvar triggerType2 udp
testvar triggerPublic2 20001-20010
testvar triggerPublicType2 udp
NOTE: Many routers will not time out the triggered port connection once
it is open. This will cause this test to fail if it is executed more
than once.
The PublicType may be either "tcp", "udp", or "both". If "both" is used,
the test case will verify both a TCP and UDP connection for each port
in the Public range.
A delay can be configured between each trigger port. This is sometimes
required for port trigger implementations using Smart ALGs. To configure
the delay, configure the testvar 'portTriggerDelay' with the number of
milliseconds.
A delay can also be configured before a trigger port is verified as being
open with WAN to LAN traffic. This is sometimes required for
implemenatations that have a delay associated with processing the outbound
trigger packet. To configure the delay, configure the testvar
'portTriggerOpenDelay' with the number of milliseconds.
Examples:
testvar portTriggerDelay 5000
testvar portTriggerOpenDelay 1000
| Test |
Module |
Name |
Synopsis |
Verify multiple LAN hosts can use trigger ports after mappings are aged out |
triggerp.tcl |
cdrouter_tport_30 |
Verify multiple LAN hosts can use trigger ports after mappings are aged out |
step 1. Read all the configured trigger ports
step 2. Create a second DHCP LAN client
step 3. Initiate a TCP or UDP session from the LAN to the WAN side
using the triggered port as the destination port
step 4. Verify the TCP or UDP session is created
step 5. For each public port that should now be triggered, open
a connection from the WAN to the LAN using the public
port as the destination port and the router's nat IP address
as the destination IP address.
step 6. Verify a connection can be estabished for each public port
step 7. Close down each public port
step 8. Close down the original LAN side connection used for the trigger
step 9. Wait for port mappings to be aged out
step 10. Repeat from step 2. using the second LAN client
step 11. Repeat for each configured port trigger
NOTE: The port mapping aging time for trigger ports is configured
using the portTriggerTimeout variable in your config file. Your
router must support the aging of trigger ports in order to run this
test.
NOTE: Up to 4096 trigger ports can be configured in your configuration
file. For example,
testvar triggerName1 net2phone-1
testvar triggerPort1 6801
testvar triggerType1 udp
testvar triggerPublic1 30000
testvar triggerPublicType1 both
NOTE: Many routers will not time out the triggered port connection once
it is open. This will cause this test to fail if it is executed more
than once.
The PublicType may be either tcp, udp, or both. If "both" is used,
the test case will verify both a TCP and UDP connection for each port
in the Public range.
A delay can be configured between each trigger port. This is sometimes
required for port trigger implementations using Smart ALGs. To configure
the delay, configure the testvar 'portTriggerDelay' with the number of
milliseconds.
A delay can also be configured before a trigger port is verified as being
open with WAN to LAN traffic. This is sometimes required for
implemenatations that have a delay associated with processing the outbound
trigger packet. To configure the delay, configure the testvar
'portTriggerOpenDelay' with the number of milliseconds.
Examples:
testvar portTriggerDelay 5000
testvar portTriggerOpenDelay 1000
upnp.tcl
UPnP tests for routers that support IGDv1/IGDv2 devices
| Test |
Module |
Name |
Synopsis |
Verify UPnP router responds to SSDP Discovery Requests on LAN |
upnp.tcl |
cdrouter_ssdp_1 |
Verify UPnP router responds to SSDP Discovery Requests on LAN |
step 1. Build a SSDP M-SEARCH request for search target "ssdp:all"
step 2. Send M-SEARCH request using unique UDP source port
step 3. Wait up to 5 seconds for all responses sent to UDP source port
step 4. For each response, verify the required headers are included
References:
UPnP Device Architecture 1.1 Section 1: Discovery
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf1
| Test |
Module |
Name |
Synopsis |
Verify UPnP router does not respond to SSDP Discovery Requests on WAN |
upnp.tcl |
cdrouter_ssdp_2 |
Verify UPnP router does not respond to SSDP Discovery Requests on WAN |
step 1. Build a SSDP M-SEARCH request for search target "ssdp:all"
step 2. Send M-SEARCH request on WAN side of router
step 3. Wait up to 5 seconds for all responses sent
step 4. Verify no responses are received
References:
UPnP Device Architecture 1.1 Section 1: Discovery
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf1
| Test |
Module |
Name |
Synopsis |
Verify UPnP router supports discovery of required IGD devices and services |
upnp.tcl |
cdrouter_ssdp_3 |
Verify UPnP router supports discovery of required IGD devices and services |
step 1. Build a M-SEARCH request for search for each required device/service
step 2. Send M-SEARCH request using unique UDP source port
step 3. Wait up to 5 seconds for all responses sent to UDP source port
step 4. For each response, verify the required headers are included
Required device and service URNs:
urn:schemas-upnp-org:device:InternetGatewayDevice:1
urn:schemas-upnp-org:device:WANDevice:1
urn:schemas-upnp-org:device:WANConnectionDevice:1
urn:schemas-upnp-org:device:LANDevice:1
urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1
urn:schemas-upnp-org:service:WANPPPConnection:1 (PPP based WAN only)
urn:schemas-upnp-org:service:WANIPConnection:1 (not required for PPP)
NOTE: Support for UPnP LANDevice:1 template is now configurable. If
the router under test does not support the LANDevice:1
template, the 'upnpLANDevice' testvar should be configured to
no. If LANDevice is supported, the testvar should be configured
to yes.
References:
InternetGatewayDevice:1 Device Template Version 1.01
http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v1-Device.pdf
WANIPConnection:1 Service Template Version 1.01
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf
WANIPConnection:2 Service Template Version 1.01
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf
| Test |
Module |
Name |
Synopsis |
Verify UPnP router does not respond to SSDP Discovery Requests without MX header |
upnp.tcl |
cdrouter_ssdp_4 |
Verify UPnP router does not respond to SSDP Discovery Requests without MX header |
step 1. Build a SSDP M-SEARCH request for search target "ssdp:all"
that does not include an MX header
step 2. Send M-SEARCH request on LAN side of router
step 3. Wait up to 5 seconds for all responses sent
step 4. Verify no responses are received
References:
UPnP Device Architecture 1.1 Section 1.3.3: Search response
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf1.3.3
| Test |
Module |
Name |
Synopsis |
Verify UPnP router responds to unicast SSDP Discovery Requests on LAN |
upnp.tcl |
cdrouter_ssdp_5 |
Verify UPnP router responds to unicast SSDP Discovery Requests on LAN |
step 1. Build a SSDP M-SEARCH request for search target "ssdp:all"
step 2. Send a unicast M-SEARCH request using unique UDP source port
step 3. Wait up to 5 seconds for all responses sent to UDP source port
step 4. For each response, verify the required headers are included
References:
UPnP Device Architecture 1.1 Section 1: Discovery
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf1
| Test |
Module |
Name |
Synopsis |
Verify required headers of M-SEARCH responses on LAN |
upnp.tcl |
cdrouter_ssdp_6 |
Verify required headers of M-SEARCH responses on LAN |
step 1. Build a SSDP M-SEARCH request for search target "ssdp:all"
step 2. Send M-SEARCH request using unique UDP source port
step 3. Wait up to 5 seconds for all responses sent to UDP source port
step 4. For each response, verify the required headers are included
References:
UPnP Device Architecture 1.1 Section 1: Discovery
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf1
| Test |
Module |
Name |
Synopsis |
Verify XML description of IGD root device can be parsed |
upnp.tcl |
cdrouter_upnp_10 |
Verify XML description of IGD root device can be parsed |
step 1. Find the description URL for the root device using SSDP
step 2. Send HTTP GET to load description URL
step 3. Verify the response can be parsed using XML parser
Required root device:
urn:schemas-upnp-org:device:InternetGatewayDevice:1
References:
InternetGatewayDevice:1 Device Template Version 1.01
http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v1-Device.pdf
| Test |
Module |
Name |
Synopsis |
Verify XML descriptions cannot be loaded from the WAN side of router |
upnp.tcl |
cdrouter_upnp_12 |
Verify XML descriptions cannot be loaded from the WAN side of router |
step 1. Find the description URL for the root device using SSDP on LAN
step 2. Send HTTP GET from the WAN side to load description URL
step 3. Send HTTP GET using router's WAN side public IP and private IP
step 4. Verify description cannot be loaded using HTTP
References:
UPnP Device Architecture 1.1 Section 1: Discovery
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf1
| Test |
Module |
Name |
Synopsis |
Verify XML description for WANIPConnection or WANPPPConnection service can be parsed |
upnp.tcl |
cdrouter_upnp_20 |
Verify XML description for WANIPConnection or WANPPPConnection service can be parsed |
step 1. Find the description URL for the WANIPConnection or
WANPPPConnection service using SSDP
step 2. Send HTTP GET to load description URL
step 3. Verify the response can be parsed using XML parser
Required service name:
urn:schemas-upnp-org:service:WANIPConnection:1
urn:schemas-upnp-org:service:WANPPPConnection:1
NOTE: The testvar 'upnpWANPPPConnection' is used to configure the test case
to use the WANPPPConnection service. Otherwise, CDRouter will test for the
WANIPConnection service.
References:
InternetGatewayDevice:1 Device Template Version 1.01
http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v1-Device.pdf
| Test |
Module |
Name |
Synopsis |
Verify router responds to UPnP Query for ConnectionStatus |
upnp.tcl |
cdrouter_upnp_25 |
Verify router responds to UPnP Query for ConnectionStatus |
step 1. Find Control URL for WANIPConnection service
step 2. Send UPnP Query for ConnectionStatus via SOAP POST
step 3. Verify ConnectionStatus variable is returned in SOAP response
NOTE: The QueryStateVariable action has been deprecated by the UPnP Forum.
This test should be skipped if the device does not support the
QueryStateVariable action.
References:
UPnP Device Architecture 1.0 Section 3.3.1: Control: Query: Invoke
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0-20080424.pdf3.3.1
| Test |
Module |
Name |
Synopsis |
Verify UPnP GetExternalIPAddress Action returns WAN IP address |
upnp.tcl |
cdrouter_upnp_30 |
Verify UPnP GetExternalIPAddress Action returns WAN IP address |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send UPnP Action for GetExternalIPAddress
step 3. Verify Action succeeds with HTTP return code 200
step 4. Verify IP address returned in the NewExternalIPAddress
attribute is the correct WAN IP address
References:
WANIPConnection:1 Service Template Version 1.01 Section 2.4.18: GetExternalIPAddress
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.18
| Test |
Module |
Name |
Synopsis |
Verify UPnP GetStatusInfo Action returns correct ConnectionStatus information |
upnp.tcl |
cdrouter_upnp_31 |
Verify UPnP GetStatusInfo Action returns correct ConnectionStatus information |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send UPnP Action for GetStatusInfo
step 3. Verify Action succeeds with HTTP return code 200
step 4. Verify returned ConnectionStatus is in the 'Connected' state
References:
WANIPConnection:1 Service Template Version 1.01 Section 2.4.9: GetStatusInfo
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.9
| Test |
Module |
Name |
Synopsis |
Verify UPnP GetStatusInfo Action returns increasing Uptime value |
upnp.tcl |
cdrouter_upnp_32 |
Verify UPnP GetStatusInfo Action returns increasing Uptime value |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send UPnP Action for GetStatusInfo
step 3. Verify Action succeeds with HTTP return code 200
step 4. Save the current Uptime
step 5. Wait 10 seconds
step 6. Send UPnP Action for GetStatusInfo
step 7. Verify Action succeeds with HTTP return code 200
step 8. Verify Uptime has increased by at least 10 seconds
References:
WANIPConnection:1 Service Template Version 1.01 Section 2.4.9: GetStatusInfo
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.9
| Test |
Module |
Name |
Synopsis |
Add/delete dynamic UPnP TCP port mapping for wildcard IP source address |
upnp.tcl |
cdrouter_upnp_35 |
Add/delete dynamic UPnP TCP port mapping for wildcard IP source address |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send UPnP Action for AddPortMapping with wildcard
for NewRemoteHost ("") and NewLeaseDuration of 0
step 3. Verify Action returns HTTP 200 status code
step 4. Initiate inbound TCP connection to new port mapping
step 5. Verify TCP connection is established
step 6. Initiate second inbound TCP connection from different IP
source address on the WAN side
step 7. Verify 2nd TCP connection is established
step 8. Close both TCP connections
step 9. Delete port mapping using DeletePortMapping Action
step 10. Wait 5 seconds for port mapping to be deleted
step 11. Initiate inbound TCP connection for port mapping from WAN side
step 12. Verify inbound TCP connection is blocked
References:
WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16
WANIPConnection:1 Service Template Version 1.01 Section 2.4.17: DeletePortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.17
| Test |
Module |
Name |
Synopsis |
Add/delete dynamic UPnP TCP port mapping for specific IP source address |
upnp.tcl |
cdrouter_upnp_36 |
Add/delete dynamic UPnP TCP port mapping for specific IP source address |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send UPnP Action for AddPortMapping with specific IP address (A)
for NewRemoteHost ("") and NewLeaseDuration of 0
step 3. Verify Action returns HTTP 200 status code
step 4. Initiate inbound TCP connection from specific IP address (A)
to new port mapping
step 5. Verify TCP connection is established
step 6. Initiate second inbound TCP connection from different IP
source address (B) on the WAN side
step 7. Verify 2nd TCP connection is blocked
step 8. Close both TCP connections
step 9. Delete port mapping using DeletePortMapping Action
step 10. Wait 5 seconds for port mapping to be deleted
step 11. Initiate inbound TCP connection for port mapping from WAN side
from specific ip address (A)
step 12. Verify inbound TCP connection is blocked
References:
WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16
WANIPConnection:1 Service Template Version 1.01 Section 2.4.17: DeletePortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.17
| Test |
Module |
Name |
Synopsis |
Add/delete dynamic UPnP UDP port mapping for wildcard IP source address |
upnp.tcl |
cdrouter_upnp_40 |
Add/delete dynamic UPnP UDP port mapping for wildcard IP source address |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send UPnP Action for AddPortMapping with wildcard
for NewRemoteHost (""), NewProtocol UDP and NewLeaseDuration of 0
step 3. Verify Action returns HTTP 200 status code
step 4. Initiate inbound UDP connection to new port mapping
step 5. Verify UDP connection is established
step 6. Initiate second inbound UDP connection from different IP
source address on the WAN side
step 7. Verify 2nd UDP connection is established
step 8. Delete port mapping using DeletePortMapping Action
step 9. Wait 5 seconds for port mapping to be deleted
step 10. Initiate inbound UDP connection for port mapping from WAN side
step 11. Verify inbound UDP connection is blocked
References:
WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16
WANIPConnection:1 Service Template Version 1.01 Section 2.4.17: DeletePortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.17
| Test |
Module |
Name |
Synopsis |
Add/delete dynamic UPnP UDP port mapping for specific IP source address |
upnp.tcl |
cdrouter_upnp_41 |
Add/delete dynamic UPnP UDP port mapping for specific IP source address |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send UPnP Action for AddPortMapping with specific IP address (A)
for NewRemoteHost (""), NewProtocol UDP and NewLeaseDuration of 0
step 3. Verify Action returns HTTP 200 status code
step 4. Initiate inbound UDP connection from specific IP address (A)
to new port mapping
step 5. Verify UDP connection is established
step 6. Initiate second inbound UDP connection from different IP
source address (B) on the WAN side
step 7. Verify 2nd UDP connection is blocked
step 8. Delete port mapping using DeletePortMapping Action
step 9. Wait 5 seconds for port mapping to be deleted
step 10. Initiate inbound UDP connection for port mapping from WAN side
from specific ip address (A)
step 11. Verify inbound UDP connection is blocked
References:
WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16
WANIPConnection:1 Service Template Version 1.01 Section 2.4.17: DeletePortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.17
| Test |
Module |
Name |
Synopsis |
Verify UPnP Router rejects new port mappings that conflict |
upnp.tcl |
cdrouter_upnp_45 |
Verify UPnP Router rejects new port mappings that conflict |
step 1. Start second client on LAN interface
step 2. Find Control URL for WANIPConnection or WANPPPConnection service
step 3. Send UPnP Action for AddPortMapping from the first DHCP client
step 4. Verify Action returns HTTP 200 status code
step 5. Send 2nd UPnP Action for AddPortMapping from the second client
using the same external port number and protocol
step 6. Verify AddPortMapping Action fails
step 7. Delete port mapping using DeletePortMapping Action
References:
WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16
| Test |
Module |
Name |
Synopsis |
Verify dynamic UPnP port mapping is deleted when lease expires |
upnp.tcl |
cdrouter_upnp_50 |
Verify dynamic UPnP port mapping is deleted when lease expires |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send UPnP Action for AddPortMapping with lease of 30 seconds
step 3. Verify Action returns HTTP 200 status code
step 4. Initiate inbound TCP connection to new port mapping
step 5. Verify TCP connection is established
step 6. Close TCP connection
step 7. Wait 45 seconds for lease to be deleted
step 8. Initiate inbound TCP connection to new port mapping
step 9. Verify TCP connection is blocked
References:
WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16
WANIPConnection:1 Service Template Version 1.01 Section 2.4.17: DeletePortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.17
| Test |
Module |
Name |
Synopsis |
Maximum number of UPnP TCP dynamic port mappings |
upnp.tcl |
cdrouter_upnp_100 |
Maximum number of UPnP TCP dynamic port mappings |
step 1. Determine the maximum number of UPnP TCP port mappings
NOTE: This is configured in your configuration file using the
the testvar 'upnpMaxTcpMappings'.
step 2. Create a unique port mapping using the AddPortMapping Action
up to the maximum number supported
step 3. For each mapping, establish an inbound TCP connection
step 4. Verify each TCP connection can be established
step 5. Delete each port mapping using the DeletePortMapping Action
References:
WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16
WANIPConnection:1 Service Template Version 1.01 Section 2.4.17: DeletePortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.17
| Test |
Module |
Name |
Synopsis |
Verify UPnP clients can subscribe/unsubcribe to events for WANIPConnection or WANPPPConnection |
upnp.tcl |
cdrouter_upnp_200 |
Verify UPnP clients can subscribe/unsubcribe to events for WANIPConnection or WANPPPConnection |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send SUBSCRIBE for eventSubURL
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. Wait for initial NOTIFY event
step 5. Send UNSUBSCRIBE for eventSubURL
step 6. Verify UNSUBSCRIBE returns HTTP 200 OK response
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Verify UPnP clients can subscribe to events with infinite subscription time |
upnp.tcl |
cdrouter_upnp_201 |
Verify UPnP clients can subscribe to events with infinite subscription time |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send SUBSCRIBE for eventSubURL using Timeout of infinite
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. Wait for initial NOTIFY event
step 5. Send UNSUBSCRIBE for eventSubURL
step 6. Verify UNSUBSCRIBE returns HTTP 200 OK response
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Verify UPnP clients can renew NOTIFY events for WANIPConnection or WANPPPConnection |
upnp.tcl |
cdrouter_upnp_202 |
Verify UPnP clients can renew NOTIFY events for WANIPConnection or WANPPPConnection |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send SUBSCRIBE for eventSubURL
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. Wait for initial NOTIFY event
step 5. Send SUBSCRIBE renewal for NOTIFY events
step 6. Verify SUBSCRIBE renewal returns HTTP 200 OK response
step 7. Send UNSUBSCRIBE for eventSubURL
step 8. Verify UNSUBSCRIBE returns HTTP 200 OK response
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Verify router sends UPnP NOTIFY events for ConnectionStatus |
upnp.tcl |
cdrouter_upnp_203 |
Verify router sends UPnP NOTIFY events for ConnectionStatus |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send SUBSCRIBE for eventSubURL
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. Wait for initial NOTIFY event
step 5. Verify ConnectionStatus is 'Connected'
step 6. Bring down WAN link
step 7. Wait for NOTIFY event with new ConnectionStatus
step 8. Verify ConnectionStatus is not 'Connected'
step 9. Bring up WAN link
step 10. Wait for NOTIFY event with new ConnectionStatus
step 11. Verify ConnectionStatus is 'Connected'
step 12. Send UNSUBSCRIBE for eventSubURL
step 13. Verify UNSUBSCRIBE returns HTTP 200 OK response
NOTE: This test is not supported when the wanMode is static.
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Verify router sends UPnP NOTIFY events with updated ExternalIPAddress |
upnp.tcl |
cdrouter_upnp_204 |
Verify router sends UPnP NOTIFY events with updated ExternalIPAddress |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send SUBSCRIBE for eventSubURL
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. Wait for initial NOTIFY event
step 5. Verify ExternalIPAddress matches current assigned WAN IP
step 6. Bring down WAN link
step 7. Bring up WAN link with new external IP address
step 8. Wait for NOTIFY event with new ExternalIPAddress
step 9. Verify ExternalIPAddress is new IP address
step 10. Bring down WAN link
step 11. Bring up WAN link with new original IP address
step 12. Wait for NOTIFY event with new ExternalIPAddress
step 13. Verify ExternalIPAddress is original IP address
step 14. Send UNSUBSCRIBE for eventSubURL
step 15. Verify UNSUBSCRIBE returns HTTP 200 OK response
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Verify router stops sending NOTIFY events when subscription expires |
upnp.tcl |
cdrouter_upnp_210 |
Verify router stops sending NOTIFY events when subscription expires |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send SUBSCRIBE for eventSubURL using minimum subscriber timeout
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. Wait for initial NOTIFY event
step 5. Verify ConnectionStatus is 'Connected'
step 6. Wait minimum subscriber timeout seconds for subscription to expire
step 7. Bring down WAN link
step 8. Wait for NOTIFY event
step 9. Verify NOTIFY event is not received
step 10. Bring up WAN link
step 11. Wait for NOTIFY event
step 12. Verify NOTIFY event is not received
step 13. Do not UNSUBSCRIBE since subscription should be expired
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Verify the maximum number of UPnP event subscriptions that can be created |
upnp.tcl |
cdrouter_upnp_220 |
Verify the maximum number of UPnP event subscriptions that can be created |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. For each event client, send SUBSCRIBE for eventSubURL
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. For each event client, wait for initial NOTIFY event
step 5. Verify ConnectionStatus is 'Connected'
step 6. Bring down WAN link
step 7. For each event client, wait for NOTIFY event with new ConnectionStatus
step 8. For each event client, verify ConnectionStatus is not 'Connected'
step 9. Bring up WAN link
step 10. For each event client, wait for NOTIFY event with new ConnectionStatus
step 11. For each event client, verify ConnectionStatus is 'Connected'
step 12. For each event client, send UNSUBSCRIBE for eventSubURL
step 13. For each event client, verify UNSUBSCRIBE returns HTTP 200 OK response
NOTE: The number of UPnP subscribers can be configured using the testvar
upnpMaxSubClients. If not configured, the default is 10 subscribers.
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Check for UPnP format string vulnerability used by BCMPUPnP_Hunter malware |
upnp.tcl |
cdrouter_upnp_400 |
Check for UPnP format string vulnerability used by BCMPUPnP_Hunter malware |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send UPnP Action for SetConnectionType with string format
step 3. Verify Action does not return HTTP 200 status code
step 4. Send UPnP Action for GetConnectionTypeInfo to trigger exploit
References:
Broadcom UPnP Remote Preauth Code Execution Vulnerability
https://www.defensecode.com/public/DefenseCode_Broadcom_Security_Advisory.pdf/
From Zero to ZeroDay Journey: Router Hacking (WRT54GL Linksys Case)
https://defensecode.com/whitepapers/From_Zero_To_ZeroDay_Network_Devices_Exploitation.txt
| Test |
Module |
Name |
Synopsis |
Verify UPnP router supports discovery of required devices and services (IGD2) |
upnp.tcl |
cdrouter_ssdp_igd2_3 |
Verify UPnP router supports discovery of required devices and services (IGD2) |
step 1. Build a M-SEARCH request for search for each required device/service
step 2. Send M-SEARCH request using unique UDP source port
step 3. Wait up to 5 seconds for all responses sent to UDP source port
step 4. For each response, verify the required headers are included
Required device and service URNs:
urn:schemas-upnp-org:device:InternetGatewayDevice:2
urn:schemas-upnp-org:device:WANDevice:2
urn:schemas-upnp-org:device:WANConnectionDevice:2
urn:schemas-upnp-org:device:LANDevice:1
urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1
urn:schemas-upnp-org:service:WANPPPConnection:1 (PPP based WAN only)
urn:schemas-upnp-org:service:WANIPConnection:2 (not required for PPP)
NOTE: Support for UPnP LANDevice:1 template is now configurable. If the
router under test does not support the LANDevice:1 template, the
'upnpLANDevice' testvar should be configured to no. If LANDevice is
supported, the testvar should be configured to yes.
References:
InternetGatewayDevice:2 Device Template Version 1.01
http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v2-Device.pdf
| Test |
Module |
Name |
Synopsis |
Verify XML description of IGD root device can be parsed (IGD2) |
upnp.tcl |
cdrouter_upnp_igd2_10 |
Verify XML description of IGD root device can be parsed (IGD2) |
step 1. Find the description URL for the root device using SSDP
step 2. Send HTTP GET to load description URL
step 3. Verify the response can be parsed using XML parser
Required root device:
urn:schemas-upnp-org:device:InternetGatewayDevice:2
References:
InternetGatewayDevice:2 Device Template Version 1.01
http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v2-Device.pdf
| Test |
Module |
Name |
Synopsis |
Verify XML descriptions cannot be loaded from the WAN side of router (IGD2) |
upnp.tcl |
cdrouter_upnp_igd2_12 |
Verify XML descriptions cannot be loaded from the WAN side of router (IGD2) |
step 1. Find the description URL for the root device using SSDP on LAN
step 2. Send HTTP GET from the WAN side to load description URL
step 3. Send HTTP GET using router's WAN side public IP and private IP
step 4. Verify description cannot be loaded using HTTP
References:
InternetGatewayDevice:2 Device Template Version 1.01
http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v2-Device.pdf
| Test |
Module |
Name |
Synopsis |
Verify XML description for WANIPConnection or WANPPPConnection service can be parsed (IGD2) |
upnp.tcl |
cdrouter_upnp_igd2_20 |
Verify XML description for WANIPConnection or WANPPPConnection service can be parsed (IGD2) |
step 1. Find the description URL for the WANIPConnection:2 or
WANPPPConnection:1 service using SSDP
step 2. Send HTTP GET to load description URL
step 3. Verify the response can be parsed using XML parser
Required service name:
urn:schemas-upnp-org:service:WANIPConnection:2
urn:schemas-upnp-org:service:WANPPPConnection:1
NOTE: The testvar 'upnpWANPPPConnection' is used to configure the
test case to use the WANPPPConnection service. Otherwise, the
router uses the WANIPConnection service.
References:
WANIPConnection:2 Service Template Version 2.00
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf
WANIPConnection:2 Service Template Version 1.01
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf
| Test |
Module |
Name |
Synopsis |
Verify router responds to UPnP Query for ConnectionStatus (IGD2) |
upnp.tcl |
cdrouter_upnp_igd2_25 |
Verify router responds to UPnP Query for ConnectionStatus (IGD2) |
step 1. Find Control URL for WANIPConnection:2 service
step 2. Send UPnP Query for ConnectionStatus via SOAP POST
step 3. Verify ConnectionStatus variable is returned in SOAP response
NOTE: The QueryStateVariable action has been deprecated by the UPnP Forum.
This test should be skipped if the device does not support the
QueryStateVariable action.
References:
UPnP Device Architecture 1.0 Section 3.3.1: Control: Query: Invoke
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0-20080424.pdf3.3.1
| Test |
Module |
Name |
Synopsis |
Verify UPnP GetExternalIPAddress Action returns WAN IP address (IGD2) |
upnp.tcl |
cdrouter_upnp_igd2_30 |
Verify UPnP GetExternalIPAddress Action returns WAN IP address (IGD2) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send UPnP Action for GetExternalIPAddress
step 3. Verify Action succeeds with HTTP return code 200
step 4. Verify IP address returned in the NewExternalIPAddress
attribute is the correct WAN IP address
References:
WANIPConnection:2 Service Template Version 2.00 Section 2.5.20: GetExternalIPAddress
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.20
| Test |
Module |
Name |
Synopsis |
Verify UPnP GetStatusInfo Action returns correct ConnectionStatus information (IGD2) |
upnp.tcl |
cdrouter_upnp_igd2_31 |
Verify UPnP GetStatusInfo Action returns correct ConnectionStatus information (IGD2) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send UPnP Action for GetStatusInfo
step 3. Verify Action succeeds with HTTP return code 200
step 4. Verify returned ConnectionStatus is in the 'Connected' state
References:
WANIPConnection:2 Service Template Version 2.00 Section 2.5.9: GetStatusInfo
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.9
| Test |
Module |
Name |
Synopsis |
Verify UPnP GetStatusInfo Action returns increasing Uptime value (IGD2) |
upnp.tcl |
cdrouter_upnp_igd2_32 |
Verify UPnP GetStatusInfo Action returns increasing Uptime value (IGD2) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send UPnP Action for GetStatusInfo
step 3. Verify Action succeeds with HTTP return code 200
step 4. Save the current Uptime
step 5. Wait 10 seconds
step 6. Send UPnP Action for GetStatusInfo
step 7. Verify Action succeeds with HTTP return code 200
step 8. Verify Uptime has increased by at least 10 seconds
References:
WANIPConnection:2 Service Template Version 2.00 Section 2.5.9: GetStatusInfo
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.9
| Test |
Module |
Name |
Synopsis |
Add/delete dynamic UPnP TCP port mapping for wildcard IP source address (IGD2) |
upnp.tcl |
cdrouter_upnp_igd2_35 |
Add/delete dynamic UPnP TCP port mapping for wildcard IP source address (IGD2) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send UPnP Action for AddPortMapping with wildcard
for NewRemoteHost ("") and NewLeaseDuration of 0
step 3. Verify Action returns HTTP 200 status code
step 4. Initiate inbound TCP connection to new port mapping
step 5. Verify TCP connection is established
step 6. Initiate second inbound TCP connection from different IP
source address on the WAN side
step 7. Verify 2nd TCP connection is established
step 8. Close both TCP connections
step 9. Delete port mapping using DeletePortMapping Action
step 10. Wait 5 seconds for port mapping to be deleted
step 11. Initiate inbound TCP connection for port mapping from WAN side
step 12. Verify inbound TCP connection is blocked
References:
WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16
WANIPConnection:2 Service Template Version 2.00 Section 2.5.18: DeletePortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.18
| Test |
Module |
Name |
Synopsis |
Add/delete dynamic UPnP TCP port mapping for specific IP source address (IGD2) |
upnp.tcl |
cdrouter_upnp_igd2_36 |
Add/delete dynamic UPnP TCP port mapping for specific IP source address (IGD2) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send UPnP Action for AddPortMapping with specific IP address (A)
for NewRemoteHost ("") and NewLeaseDuration of 0
step 3. Verify Action returns HTTP 200 status code
step 4. Initiate inbound TCP connection from specific IP address (A)
to new port mapping
step 5. Verify TCP connection is established
step 6. Initiate second inbound TCP connection from different IP
source address (B) on the WAN side
step 7. Verify 2nd TCP connection is blocked
step 8. Close both TCP connections
step 9. Delete port mapping using DeletePortMapping Action
step 10. Wait 5 seconds for port mapping to be deleted
step 11. Initiate inbound TCP connection for port mapping from WAN side
from specific ip address (A)
step 12. Verify inbound TCP connection is blocked
References:
WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16
WANIPConnection:2 Service Template Version 2.00 Section 2.5.18: DeletePortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.18
| Test |
Module |
Name |
Synopsis |
Add/delete dynamic UPnP UDP port mapping for wildcard IP source address (IGD2) |
upnp.tcl |
cdrouter_upnp_igd2_40 |
Add/delete dynamic UPnP UDP port mapping for wildcard IP source address (IGD2) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send UPnP Action for AddPortMapping with wildcard
for NewRemoteHost (""), NewProtocol UDP and NewLeaseDuration of 0
step 3. Verify Action returns HTTP 200 status code
step 4. Initiate inbound UDP connection to new port mapping
step 5. Verify UDP connection is established
step 6. Initiate second inbound UDP connection from different IP
source address on the WAN side
step 7. Verify 2nd UDP connection is established
step 8. Delete port mapping using DeletePortMapping Action
step 9. Wait 5 seconds for port mapping to be deleted
step 10. Initiate inbound UDP connection for port mapping from WAN side
step 11. Verify inbound UDP connection is blocked
References:
WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16
WANIPConnection:2 Service Template Version 2.00 Section 2.5.18: DeletePortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.18
| Test |
Module |
Name |
Synopsis |
Add/delete dynamic UPnP UDP port mapping for specific IP source address (IGD2) |
upnp.tcl |
cdrouter_upnp_igd2_41 |
Add/delete dynamic UPnP UDP port mapping for specific IP source address (IGD2) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send UPnP Action for AddPortMapping with specific IP address (A)
for NewRemoteHost (""), NewProtocol UDP and NewLeaseDuration of 0
step 3. Verify Action returns HTTP 200 status code
step 4. Initiate inbound UDP connection from specific IP address (A)
to new port mapping
step 5. Verify UDP connection is established
step 6. Initiate second inbound UDP connection from different IP
source address (B) on the WAN side
step 7. Verify 2nd UDP connection is blocked
step 8. Delete port mapping using DeletePortMapping Action
step 9. Wait 5 seconds for port mapping to be deleted
step 10. Initiate inbound UDP connection for port mapping from WAN side
from specific ip address (A)
step 11. Verify inbound UDP connection is blocked
References:
WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16
WANIPConnection:2 Service Template Version 2.00 Section 2.5.18: DeletePortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.18
| Test |
Module |
Name |
Synopsis |
Verify UPnP Router rejects new port mappings that conflict (IGD2) |
upnp.tcl |
cdrouter_upnp_igd2_45 |
Verify UPnP Router rejects new port mappings that conflict (IGD2) |
step 1. Start second client on LAN interface
step 2. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 3. Send UPnP Action for AddPortMapping from the first DHCP client
step 4. Verify Action returns HTTP 200 status code
step 5. Send 2nd UPnP Action for AddPortMapping from the second client
using the same external port number and protocol
step 6. Verify AddPortMapping Action fails
step 7. Delete port mapping using DeletePortMapping Action
References:
WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16
| Test |
Module |
Name |
Synopsis |
Verify dynamic UPnP port mapping is deleted when lease expires (IGD2) |
upnp.tcl |
cdrouter_upnp_igd2_50 |
Verify dynamic UPnP port mapping is deleted when lease expires (IGD2) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send UPnP Action for AddPortMapping with lease of 30 seconds
step 3. Verify Action returns HTTP 200 status code
step 4. Initiate inbound TCP connection to new port mapping
step 5. Verify TCP connection is established
step 6. Close TCP connection
step 7. Wait 45 seconds for lease to be deleted
step 8. Initiate inbound TCP connection to new port mapping
step 9. Verify TCP connection is blocked
References:
WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16
| Test |
Module |
Name |
Synopsis |
Maximum number of UPnP TCP dynamic port mappings (IGD2) |
upnp.tcl |
cdrouter_upnp_igd2_100 |
Maximum number of UPnP TCP dynamic port mappings (IGD2) |
step 1. Determine the maximum number of UPnP TCP port mappings
NOTE: This is configured in your configuration file using the
the testvar 'upnpMaxTcpMappings'.
step 2. Create a unique port mapping using the AddPortMapping Action
up to the maximum number supported
step 3. For each mapping, establish an inbound TCP connection
step 4. Verify each TCP connection can be established
step 5. Delete each port mapping using the DeletePortMapping Action
References:
WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16
WANIPConnection:2 Service Template Version 2.00 Section 2.5.18: DeletePortMapping
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.18
| Test |
Module |
Name |
Synopsis |
Verify UPnP clients can subscribe/unsubcribe to events for WANIPConnection or WANPPPConnection (IGD2) |
upnp.tcl |
cdrouter_upnp_igd2_200 |
Verify UPnP clients can subscribe/unsubcribe to events for WANIPConnection or WANPPPConnection (IGD2) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send SUBSCRIBE for eventSubURL
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. Wait for initial NOTIFY event
step 5. Send UNSUBSCRIBE for eventSubURL
step 6. Verify UNSUBSCRIBE returns HTTP 200 OK response
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Verify UPnP clients can subscribe to events with infinite subscription time (IGD2) |
upnp.tcl |
cdrouter_upnp_igd2_201 |
Verify UPnP clients can subscribe to events with infinite subscription time (IGD2) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send SUBSCRIBE for eventSubURL using Timeout of infinite
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. Wait for initial NOTIFY event
step 5. Send UNSUBSCRIBE for eventSubURL
step 6. Verify UNSUBSCRIBE returns HTTP 200 OK response
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Verify UPnP clients can renew NOTIFY events for WANIPConnection or WANPPPConnection (IGD2) |
upnp.tcl |
cdrouter_upnp_igd2_202 |
Verify UPnP clients can renew NOTIFY events for WANIPConnection or WANPPPConnection (IGD2) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send SUBSCRIBE for eventSubURL
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. Wait for initial NOTIFY event
step 5. Send SUBSCRIBE renewal for NOTIFY events
step 6. Verify SUBSCRIBE renewal returns HTTP 200 OK response
step 7. Send UNSUBSCRIBE for eventSubURL
step 8. Verify UNSUBSCRIBE returns HTTP 200 OK response
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Verify router sends UPnP NOTIFY events for ConnectionStatus (IGD2) |
upnp.tcl |
cdrouter_upnp_igd2_203 |
Verify router sends UPnP NOTIFY events for ConnectionStatus (IGD2) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send SUBSCRIBE for eventSubURL
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. Wait for initial NOTIFY event
step 5. Verify ConnectionStatus is 'Connected'
step 6. Bring down WAN link
step 7. Wait for NOTIFY event with new ConnectionStatus
step 8. Verify ConnectionStatus is not 'Connected'
step 9. Bring up WAN link
step 10. Wait for NOTIFY event with new ConnectionStatus
step 11. Verify ConnectionStatus is 'Connected'
step 12. Send UNSUBSCRIBE for eventSubURL
step 13. Verify UNSUBSCRIBE returns HTTP 200 OK response
NOTE: This test is not supported when the wanMode is static.
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Verify router sends UPnP NOTIFY events with updated ExternalIPAddress (IGD2) |
upnp.tcl |
cdrouter_upnp_igd2_204 |
Verify router sends UPnP NOTIFY events with updated ExternalIPAddress (IGD2) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send SUBSCRIBE for eventSubURL
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. Wait for initial NOTIFY event
step 5. Verify ExternalIPAddress matches current assigned WAN IP
step 6. Bring down WAN link
step 7. Bring up WAN link with new external IP address
step 8. Wait for NOTIFY event with new ExternalIPAddress
step 9. Verify ExternalIPAddress is new IP address
step 10. Bring down WAN link
step 11. Bring up WAN link with new original IP address
step 12. Wait for NOTIFY event with new ExternalIPAddress
step 13. Verify ExternalIPAddress is original IP address
step 14. Send UNSUBSCRIBE for eventSubURL
step 15. Verify UNSUBSCRIBE returns HTTP 200 OK response
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Verify router stops sending NOTIFY events when subscription expires (IGD2) |
upnp.tcl |
cdrouter_upnp_igd2_210 |
Verify router stops sending NOTIFY events when subscription expires (IGD2) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. Send SUBSCRIBE for eventSubURL using minimum subscriber timeout
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. Wait for initial NOTIFY event
step 5. Verify ConnectionStatus is 'Connected'
step 6. Wait minimum subscriber timeout seconds for subscription to expire
step 7. Bring down WAN link
step 8. Wait for NOTIFY event
step 9. Verify NOTIFY event is not received
step 10. Bring up WAN link
step 11. Wait for NOTIFY event
step 12. Verify NOTIFY event is not received
step 13. Do not UNSUBSCRIBE since subscription should be expired
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Verify the maximum number of UPnP event subscriptions that can be created (IGD2) |
upnp.tcl |
cdrouter_upnp_igd2_220 |
Verify the maximum number of UPnP event subscriptions that can be created (IGD2) |
step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
step 2. For each event client, send SUBSCRIBE for eventSubURL
step 3. Verify SUBSCRIBE returns HTTP 200 OK response
step 4. For each event client, wait for initial NOTIFY event
step 5. Verify ConnectionStatus is 'Connected'
step 6. Bring down WAN link
step 7. For each event client, wait for NOTIFY event with new ConnectionStatus
step 8. For each event client, verify ConnectionStatus is not 'Connected'
step 9. Bring up WAN link
step 10. For each event client, wait for NOTIFY event with new ConnectionStatus
step 11. For each event client, verify ConnectionStatus is 'Connected'
step 12. For each event client, send UNSUBSCRIBE for eventSubURL
step 13. For each event client, verify UNSUBSCRIBE returns HTTP 200 OK response
NOTE: The number of UPnP subscribers can be configured using the testvar
upnpMaxSubClients. If not configured, the default is 10 subscribers.
References:
UPnP Device Architecture 1.1 Section 4.0: Eventing
http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0
| Test |
Module |
Name |
Synopsis |
Check for UPnP format string vulnerability used by BCMPUPnP_Hunter malware |
upnp.tcl |
cdrouter_upnp_igd2_400 |
Check for UPnP format string vulnerability used by BCMPUPnP_Hunter malware |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send UPnP Action for SetConnectionType with string format
step 3. Verify Action does not return HTTP 200 status code
step 4. Send UPnP Action for GetConnectionTypeInfo to trigger exploit
References:
Broadcom UPnP Remote Preauth Code Execution Vulnerability
https://www.defensecode.com/public/DefenseCode_Broadcom_Security_Advisory.pdf/
From Zero to ZeroDay Journey: Router Hacking (WRT54GL Linksys Case)
https://defensecode.com/whitepapers/From_Zero_To_ZeroDay_Network_Devices_Exploitation.txt
pptp-pt.tcl
PPTP based VPN pass through from the LAN to the WAN
| Test |
Module |
Name |
Synopsis |
PPTP control session can be established at port 1723 |
pptp-pt.tcl |
cdrouter_pptppt_1 |
PPTP control session can be established at port 1723 |
step 1. Create PPTP sever on WAN side of the router
step 2. Initiate TCP session from LAN to port 1723 on PPTP server
step 3. Verify TCP session can be established
step 4. Initiate PPTP control session
step 5. Initiate new outbound PPTP call from LAN side
step 6. Verify PPTP call is established
step 7. Close TCP session from LAN side
References:
IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)"
https://tools.ietf.org/html/rfc2637
| Test |
Module |
Name |
Synopsis |
Tunneled PPTP data packets pass through router (PPP over GRE) |
pptp-pt.tcl |
cdrouter_pptppt_2 |
Tunneled PPTP data packets pass through router (PPP over GRE) |
step 1. Initiate outbound PPTP call using unique PPTP tunnel endpoint
step 2. Verify PPTP control session is established and call is accepted
step 3. Initiate an ICMP Echo Request on the LAN host through a PPTP tunnel
step 4. Send the ICMP packet as a tunneled PPP over GRE packet
step 5. Verify the tunneled PPP over GRE packet is received on the WAN host
step 6. Respond to the ICMP Echo Request on the WAN side
step 7. Send the ICMP Echo Reply as a tunneled PPP over GRE packet
References:
IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)"
https://tools.ietf.org/html/rfc2637
| Test |
Module |
Name |
Synopsis |
Verify the max number of PPTP pass through connections for a single LAN host |
pptp-pt.tcl |
cdrouter_pptppt_100 |
Verify the max number of PPTP pass through connections for a single LAN host |
step 1. Initiate outbound PPTP call using unique PPTP tunnel endpoint
step 2. Verify PPTP control session is established and call is accepted
step 3. Forward an ICMP Echo Request from LAN to unique WAN IP address using
a unique PPTP tunnel endpoint IP address
step 4. Verify the packet is received on the WAN
step 5. Send an ICMP Echo Reply to LAN using PPTP tunnel
step 6. Verify the ICMP Echo Reply is received on the LAN
step 7. Repeat up to the pptpMaxTunnels value
Note: Each PPTP tunnel uses a unique IP address as its PPTP tunnel
endpoint. The ICMP Echo Request is also sent to a unique IP destination
address that is routed over the PPTP tunnel on the LAN.
References:
IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)"
https://tools.ietf.org/html/rfc2637
l2tp-pt.tcl
L2TP based VPN pass through from the LAN to the WAN
| Test |
Module |
Name |
Synopsis |
Verify L2TP session passes through router |
l2tp-pt.tcl |
cdrouter_l2tppt_1 |
Verify L2TP session passes through router |
step 1. Initiate outbound L2TP tunnel to L2TP server
step 2. Verify L2TP session is established
step 3. Initiate PPP session over L2TP tunnel
step 4. Verify ICMP echo across tunnel
NOTE: This test case uses L2TP directly over UDP without IPSEC. L2TP clients
from Microsoft normally run L2TP over IPSEC. L2TP over IPSEC pass through
is covered by test case cdrouter_l2tppt_2.
References:
IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""
https://tools.ietf.org/html/rfc2661
| Test |
Module |
Name |
Synopsis |
Verify L2TP over IPSEC session passes through router |
l2tp-pt.tcl |
cdrouter_l2tppt_2 |
Verify L2TP over IPSEC session passes through router |
step 1. Initiate IKE transport mode tunnel to L2TP server
step 2. Initiate outbound L2TP call to L2TP server
step 3. Verify L2TP tunnel is established
step 4. Initiate PPP session over L2TP tunnel
step 5. Verify ICMP echo across tunnel
References:
IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""
https://tools.ietf.org/html/rfc2661
| Test |
Module |
Name |
Synopsis |
Verify L2TP over IPSEC with NAT-T passes through router |
l2tp-pt.tcl |
cdrouter_l2tppt_10 |
Verify L2TP over IPSEC with NAT-T passes through router |
step 1. Initiate IKE transport mode tunnel with NAT-T to L2TP server
step 2. Initiate outbound L2TP call to L2TP server
step 3. Verify L2TP tunnel is established
step 4. Initiate PPP session over L2TP tunnel
step 5. Verify ICMP echo across tunnel
References:
IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""
https://tools.ietf.org/html/rfc2661
eapol.tcl
Basic EAPOL tests for all types of EAP
| Test |
Module |
Name |
Synopsis |
Authenticator sends EAPOL packets to correct MAC address |
eapol.tcl |
cdrouter_eapol_1 |
Authenticator sends EAPOL packets to correct MAC address |
step 1. Unauthorize the supplicant interface
step 2. Start authentication on the supplicant interface
step 3. Wait for EAPOL packet from authenticator (up to txWhen seconds)
step 4. For wireless supplicants, verify that the destination MAC address
of the packet received in step 3 is the supplicant's unicast MAC
address; for wired supplicants, verify that the destination MAC
address is the supplicant's unicast MAC address or the PAE group
address 01:80:C2:00:00:03
NOTE: The authenticator should be in the CONNECTING state after the
EAPOL-Logoff/EAPOL-Start packets are sent by the supplicant.
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 7.8: EAPOL Addressing
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Basic case of authenticator initiated authentication |
eapol.tcl |
cdrouter_eapol_2 |
Basic case of authenticator initiated authentication |
step 1. Send EAPOL-Logoff to place controlled port in unauthorized state
step 2. Initiate ping on LAN port to remote WAN host
step 3. Continue ping attempts for 120 seconds
step 4. Verify authentication occurs for the configured type
step 5. Verify ping is received by remote host on the WAN
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.4.2.1: Authenticator Initiation
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Basic case of supplicant initiated authentication |
eapol.tcl |
cdrouter_eapol_3 |
Basic case of supplicant initiated authentication |
step 1. Unauthorize supplicant interface
step 2. Start authentication on supplicant interface
step 3. Verify authentication occurs for the configured type
step 4. Verify ping to remote host on the WAN
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.4.2.2: Supplicant Initiation
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Authenticator sends EAP Failure after supplicant sends EAPOL-Logoff |
eapol.tcl |
cdrouter_eapol_6 |
Authenticator sends EAP Failure after supplicant sends EAPOL-Logoff |
step 1. Send EAPOL-Logoff to place controlled port in unauthorized state
step 2. Wait up to 15 seconds for EAP Failure packet from Authenticator
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.4.4: Disconnected
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Authenticator sends EAP Failure if identity is unknown |
eapol.tcl |
cdrouter_eapol_8 |
Authenticator sends EAP Failure if identity is unknown |
step 1. Configure the supplicant to use unknown identity
step 2. Start authentication on supplicant interface
step 3. Wait for EAP Identity Request
step 4. Respond with unknown identity
step 5. Verify an EAP Failure is received
NOTE: This test uses the Identity 'badUserName' which must not be a valid
user name on your back-end authentication server.
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.6: FAIL
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Authenticator sends EAP Failure if authentication challenge fails |
eapol.tcl |
cdrouter_eapol_9 |
Authenticator sends EAP Failure if authentication challenge fails |
step 1. Configure the supplicant to use known identity
step 2. Start authentication on supplicant interface
step 3. Wait for EAP Identity Request
step 4. Respond with known identity
step 5. Wait for EAP authentication challenge (MD5, TLS, PEAP, SIM, etc)
step 6. Respond with authentication data that fails challenge
step 7. Verify an EAP Failure is received
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.6: FAIL
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Authenticator retransmits EAP Identity Request if no response is received |
eapol.tcl |
cdrouter_eapol_20 |
Authenticator retransmits EAP Identity Request if no response is received |
step 1. Unauthorize supplicant interface
step 2. Start authentication on supplicant interface
step 3. Wait txWhen seconds for EAP Identity Request
step 4. Do not respond
step 5. Wait txWhen seconds for EAP Identity Request
step 6. Repeat up to reAuthMax attempts
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.4.5: Connecting
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Authenticator uses same EAP identifier for each retransmitted identity request |
eapol.tcl |
cdrouter_eapol_21 |
Authenticator uses same EAP identifier for each retransmitted identity request |
step 1. Unauthorize supplicant interface
step 2. Start authentication on supplicant interface
step 3. Wait txWhen seconds for EAP Identity Request
step 4. Do not respond
step 5. Wait txWhen seconds for EAP Identity Request
step 6. Verify the EAP identifier does not change
step 7. Repeat up to reAuthMax attempts
NOTE: After the authenticator enters the Disconnected state, it should
transition back to the Connecting state. Once in the Connecting state, the
authenticator should reuse the current ID each time the EAP Idenitity
request is retransmitted.
NOTE: The test checks that identifier does not change. It is possible that
some EAP Identity packets are not received during the disassociate and
reconnect process.
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.4.4: Disconnected
https://standards.ieee.org/standard/802_1X-2001.html
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.4.5: Connecting
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Authenticator ignores EAP Identity Responses with unknown id field |
eapol.tcl |
cdrouter_eapol_23 |
Authenticator ignores EAP Identity Responses with unknown id field |
step 1. Unauthorize supplicant interface
step 2. Start authentication on supplicant interface
step 3. Wait txWhen seconds for EAP RetryIdentity Request
step 4. Respond with EAP Identity Response with mismatched Id field
step 5. Verify Authenticator resends EAP Identity Request
step 6. Verify the EAP identifier does not change
step 7. Repeat up to reAuthMax attempts
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.4.5: Connecting
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Authenticator enters the held state after authentication is rejected |
eapol.tcl |
cdrouter_eapol_24 |
Authenticator enters the held state after authentication is rejected |
step 1. Configure the supplicant with bad authentication data (password/cert)
step 2. Send EAPOL-Start
step 3. Wait for EAP Identity Request
step 4. Respond with identity
step 5. Wait for authentication challenge
step 6. Send bad authentication data (bad md5, invalid cert, etc)
step 5. Verify an EAP Failure is received
step 6. Authenticator should move to the HELD state
step 7. Continue to send EAPOL-Start packets
step 8. Verify no EAP Identity Request is received under the quietWhile
timer expires
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.4.6: Authenticating
https://standards.ieee.org/standard/802_1X-2001.html
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.4.9: Held
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
No packets are forwarded/processed when port is in unauthorized state |
eapol.tcl |
cdrouter_eapol_100 |
No packets are forwarded/processed when port is in unauthorized state |
step 1. Unauthorize supplicant interface
step 2. Send ARP request for router's LAN IP address
step 3. Verify no response is received
step 4. Send ping to remoteHost on WAN using PAE group MAC address
step 5. Verify ping is not forwarded to WAN
step 6. Send ping to remoteHost on LAN using broadcast MAC address
step 7. Verify ping is not forwarded to WAN
step 8. Bring authenticator to the CONNECTING state
step 9. Repeat forwarding tests and verify no packets are forwarded
step 10. Bring authenticator to the AUTHENTICATING state
step 11. Repeat forwarding tests and verify no packets are forwarded
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.1: Purpose
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Inbound traffic is blocked when port is in unauthorized state |
eapol.tcl |
cdrouter_eapol_105 |
Inbound traffic is blocked when port is in unauthorized state |
step 1. Bring port to authenticated state
step 2. Initiate traffic to remote host on WAN
step 3. Verify packet is received on the WAN
step 4. Initiate traffic from WAN host back to LAN host
step 5. Verify packet is received on the LAN
step 6. Unauthorize controlled port
step 7. Do not respond to any EAP request
step 8. Initiate traffic from WAN host back to LAN host
step 9. Verify traffic is not forwarded to LAN
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.1: Purpose
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Packets are forwarded during reauthentication if port is in authenticated state |
eapol.tcl |
cdrouter_eapol_110 |
Packets are forwarded during reauthentication if port is in authenticated state |
step 1. Send EAPOL-Logoff to place controlled port in unauthorized state
step 2. Bring port to authenticated state
step 3. Send EAPOL-Start to initiate reauthentication process
step 4. Send ARP request for router's LAN IP address
step 5. Verify ARP response is received
step 6. Send ping to remoteHost on WAN
step 7. Verify ping response is received on LAN
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.4.5: Connecting
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Port is placed in unauthenticated state if reauthentication fails (bad identity) |
eapol.tcl |
cdrouter_eapol_112 |
Port is placed in unauthenticated state if reauthentication fails (bad identity) |
step 1. Unauthorize supplicant interface
step 2. Start authentication with valid identity
step 3. Verify authentication succeeds
step 4. Restart authentication using an unknown identity
step 5. Verify authentication fails
step 6. Send ARP request for router's LAN IP address
step 7. Verify no response is received
step 8. Send UDP packet to remoteHost on WAN
step 9. Verify UDP packet is not forwarded to LAN
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.4.6: Authenticating
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Port is placed in unauthorized state if reauthentication fails (bad auth) |
eapol.tcl |
cdrouter_eapol_113 |
Port is placed in unauthorized state if reauthentication fails (bad auth) |
step 1. Unauthorize supplicant interface
step 2. Start authentication with valid identity
step 3. Verify authentication succeeds
step 4. Restart authentication using an bad authentication data (md5/tls)
step 5. Verify authentication fails
step 6. Send UDP packet to remoteHost on WAN
step 7. Verify UDP packet is not forwarded to LAN
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.4.6: Authenticating
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Port becomes unauthorized if no response to EAP Identity request is received |
eapol.tcl |
cdrouter_eapol_115 |
Port becomes unauthorized if no response to EAP Identity request is received |
step 1. Unauthorize supplicant interface
step 2. Start authentication on supplicant interface
step 3. Verify authentication succeeds
step 4. Restart authentication on supplicant interface
step 5. Do not respond to any EAP packets
step 6. Wait for all EAP Identity Requests to timeout
step 7. Verify port is not in unauthorized state
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.4.5: Connecting
https://standards.ieee.org/standard/802_1X-2001.html
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.7: Timeout
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
EAP Success packets from supplicant do not authorize port |
eapol.tcl |
cdrouter_eapol_117 |
EAP Success packets from supplicant do not authorize port |
step 1. Unauthorize supplicant interface
step 2. Start authentication on supplicant interface
step 3. Respond to identity request
step 4. Wait for EAP Request to begin authenticating process
step 5. Send EAP Success using ID from EAP Request
step 6. Send ARP request to LAN interface of router
step 7. Verify no ARP response is received
step 8. Send ping to remoteHost on WAN
step 9. Verify ping is not forwarded to WAN
NOTE: The Authenticator should not authorize the port when an EAP-Success
packet is received from the supplicant. This packet is normally relayed to
the Back-end to process. Some implementations will reject the relayed
EAP-Success as an invalid packet and send an EAP-Failure.
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.4.7: Relaying EAP Frames
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Authenticator initiates reauthentication with supplicant every reAuthPeriod |
eapol.tcl |
cdrouter_eapol_130 |
Authenticator initiates reauthentication with supplicant every reAuthPeriod |
step 1. Unauthorize supplicant interface
step 2. Initiate EAP authentication
step 3. Verify authentication succeeds
step 4. Wait up to reAuthPeriod seconds for authenticator to reauthenticate
step 5. Verify reauthentication occurs within reAuthPeriod
NOTE: The EAP reAuthPeriod interval is configured using the
'eapReAuthPeriod' testvar. The default interval is 3600 seconds. If the
'eapReAuthPeriod' testvar is set to 0, this test will be skipped.
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.7: Reauthentication Timer state machine
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Port is placed in unauthorized state if 802.11 layer is reinitialized |
eapol.tcl |
cdrouter_eapol_140 |
Port is placed in unauthorized state if 802.11 layer is reinitialized |
step 1. Unauthorize supplicant interface
step 2. Start authentication with valid identity
step 3. Verify authentication succeeds
step 4. Reassociate to AP with out performing authentication.
(This will cause the 802.11 layer to reset)
step 5. Do not respond to any EAP requests
step 6. Send ping to remote host on WAN
step 7. Verify the ping fails
step 8. Start authentication on supplicant interface
step 9. Verify authentication succeeds
step 10. Send ping to remote host on WAN
step 11. Verify the ping succeeds
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.4.2: Authentication initiation
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Verify supplicant can login using all configured Identities |
eapol.tcl |
cdrouter_eapol_300 |
Verify supplicant can login using all configured Identities |
step 1. Unauthorize supplicant interface
step 2. For each configured EAP Identity
step 3. Configure the supplicant to use the next Identity
step 4. Start authentication on supplicant interface
step 5. Verify successful authentication occurs
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.4: Protocol Operation
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Authenticator handles EAP Start flood DoS attack |
eapol.tcl |
cdrouter_eapol_500 |
Authenticator handles EAP Start flood DoS attack |
step 1. Flood 100 EAPOL-Start packets
step 2. Send ping to host on the WAN to verify port is operational
step 3. Verify ping is received
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control"
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Authenticator handles EAP Logoff flood DoS attack |
eapol.tcl |
cdrouter_eapol_501 |
Authenticator handles EAP Logoff flood DoS attack |
step 1. Flood 100 EAPOL-Logoff packets
step 2. Send ping to host on the WAN to verify port is operational
step 3. Verify ping is received
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control"
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Authenticator handles EAP-of-Death DoS attack |
eapol.tcl |
cdrouter_eapol_502 |
Authenticator handles EAP-of-Death DoS attack |
step 1. Start authentication on supplicant interface
step 2. Wait for EAP Request Identity packet
step 3. Respond with EAP Identity Reply with length field = 0xffff
step 4. Repeat step 2 and 3
step 5. Start authentication on supplicant interface with normal behavior
step 6. Verify normal authentication occurs
step 7. Verify LAN port can ping remote host on WAN
NOTE: The length field for an EAP packet is 2 bytes. This allows
a maximum EAP packet size of 0xffff. However, EAPOL can only carry
EAP packets with a length less than the Ethernet MTU. This test
verifies that the authenticator handles these invalid packets
gracefully.
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control"
https://standards.ieee.org/standard/802_1X-2001.html
IETF RFC 2284 "PPP Extensible Authentication Protocol (EAP)"
https://tools.ietf.org/html/rfc2284
| Test |
Module |
Name |
Synopsis |
Back-end flood DoS attack |
eapol.tcl |
cdrouter_eapol_503 |
Back-end flood DoS attack |
step 1. Unauthorize supplicant interface
step 2. Start authentication on supplicant interface
step 3. Respond to identity request
step 4. Wait for EAP Request to begin authenticating process
step 5. Flood back-end with 100 EAP Responses with invalid authentication data
step 6. Start authentication on supplicant interface with normal behavior
step 7. Verify normal authentication occurs
step 8. Verify LAN port can ping remote host on WAN
NOTE: This test trys to exploit the EAP relay beahvior of the authenticator.
Once the EAP session reaches the authentication stage, the supplicant will
flood the back-end with EAP Response which should be handled gracefully by
the Authenticator and back-end.
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control"
https://standards.ieee.org/standard/802_1X-2001.html
eap-md5.tcl
EAPOL tests specific to EAP-MD5
| Test |
Module |
Name |
Synopsis |
Authenticator sends EAP Failure if MD5 Challenge Response is invalid |
eap-md5.tcl |
cdrouter_eapmd5_10 |
Authenticator sends EAP Failure if MD5 Challenge Response is invalid |
step 1. Send EAPOL-Start
step 2. Wait for EAP Identity Request
step 3. Respond with known identity
step 4. Wait for EAP authentication MD5 Challenge Request
step 5. Respond with valid authentication value, but include different
EAP Identity after the MD5 Challenge Response
step 6. Verify an EAP Failure is received
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.6: FAIL
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Authenticator sends EAP Failure if no response to EAP MD5 Challenge Request is received |
eap-md5.tcl |
cdrouter_eapmd5_20 |
Authenticator sends EAP Failure if no response to EAP MD5 Challenge Request is received |
step 1. Send EAPOL-Logoff to place controlled port in unauthorized state
step 2. Bring authenticator to the AUTHENTICATING state
step 3. Wait txWhen seconds for EAP MD5 Challenge Request
step 4. Do not respond
step 5. Verify authenticator sends an EAP Failure
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.7: Timeout
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Authenticator ignores EAP MD5 Responses with unknown id field |
eap-md5.tcl |
cdrouter_eapmd5_23 |
Authenticator ignores EAP MD5 Responses with unknown id field |
step 1. Send EAPOL-Logoff to place controlled port in unauthorized state
step 2. Bring authenticator to the AUTHENTICATING state
step 3. Wait txWhen seconds for EAP MD5 Challenge Request
step 4. Respond with EAP MD5 Challenge Response with mismatched Id field
step 5. Verify Authenticator does not send EAP Success
NOTE: This test verifies that the Backend Authentication State machine
checks the EAP Challenge Response identifier to verify that it matches the
request identifier. Some implementations will silently ignore a mismatch and
eventually trigger a TIMEOUT. Other implementations will generate an EAP
Failure message. This test only verifies that the Backend does not generate
an EAP Success.
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.3: REQUEST
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Authenticator handles EAP MD5 Challenge Request DoS attack |
eap-md5.tcl |
cdrouter_eapmd5_500 |
Authenticator handles EAP MD5 Challenge Request DoS attack |
step 1. Send EAPOL-Start
step 2. Wait for EAP Identity request
step 3. Respond with known identity
step 4. Wait for EAP authentication MD5 Challenge Request
step 5. Respond with bad authentication length
step 6. Repeat for 200 MD5 Challenge Requests
Reference: IEEE Std 802.1X-2001
NOTE: In this DoS attach, the MD5 Challenge Response is returned with a
value length of 255. However, only 16 bytes of the actual MD5 value are
included. The Backend Authentication server must handle the parsing failure
of the packet.
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control"
https://standards.ieee.org/standard/802_1X-2001.html
eap-tls.tcl
EAPOL tests specific to EAP-TLS
| Test |
Module |
Name |
Synopsis |
Authenticator sends EAP Failure when TLS client fails to authenticate server |
eap-tls.tcl |
cdrouter_eaptls_10 |
Authenticator sends EAP Failure when TLS client fails to authenticate server |
step 1. Start authentication on supplicant interface
step 2. Wait for EAP Identity Request
step 3. Respond with known identity
step 4. Wait for EAP-TLS Start
step 5. Complete TLS session using invalid root CA certificate
step 6. Verify an EAP Failure is received
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.6: FAIL
https://standards.ieee.org/standard/802_1X-2001.html
IETF RFC 2716 "PPP EAP TLS Authentication Protocol" Section 3.1: Overview of the EAP-TLS conversation
https://tools.ietf.org/html/rfc2716#section-3.1
| Test |
Module |
Name |
Synopsis |
Authenticator sends EAP Failure when TLS server fails to authenticate client |
eap-tls.tcl |
cdrouter_eaptls_12 |
Authenticator sends EAP Failure when TLS server fails to authenticate client |
step 1. Start authentication on supplicant interface
step 2. Wait for EAP Identity Request
step 3. Respond with known identity
step 4. Wait for EAP-TLS Start
step 5. Complete TLS session using invalid client certificate
step 6. Verify an EAP Failure is received
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.6: FAIL
https://standards.ieee.org/standard/802_1X-2001.html
IETF RFC 2716 "PPP EAP TLS Authentication Protocol" Section 3.1: Overview of the EAP-TLS conversation
https://tools.ietf.org/html/rfc2716#section-3.1
| Test |
Module |
Name |
Synopsis |
Port becomes unauthorized if no response to EAP-TLS Start request is received |
eap-tls.tcl |
cdrouter_eaptls_20 |
Port becomes unauthorized if no response to EAP-TLS Start request is received |
step 1. Unauthorize supplicant interface
step 2. Bring authenticator to the AUTHENTICATING state
step 3. Wait txWhen seconds for EAP-TLS Start request
step 4. Do not respond
step 5. Wait for EAP-TLS Start to be retransmitted up to
eapReAuthMax times
step 6. Verify port is not in unauthorized state
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.7: Timeout
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Authenticator ignores EAP-TLS Response with unknown id field |
eap-tls.tcl |
cdrouter_eaptls_23 |
Authenticator ignores EAP-TLS Response with unknown id field |
step 1. Unauthorize supplicant interface
step 2. Bring authenticator to the AUTHENTICATING state
step 3. Wait txWhen seconds for EAP-TLS Request
step 4. Respond with EAP-TLS Response with mismatched Id field
step 5. Verify Authenticator does not send EAP Success
NOTE: This test verifies that the Backend Authentication State machine
checks the EAP Response identifier to verify that it matches the request
identifier. Some implementations will silently ignore a mismatch and
eventually trigger a TIMEOUT. Other implementations will generate an EAP
Failure message. This test only verifies that the Backend does not generate
an EAP Success.
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.3: REQUEST
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Backend sends TLS Alert if supplicant fails server TLS authentication |
eap-tls.tcl |
cdrouter_eaptls_40 |
Backend sends TLS Alert if supplicant fails server TLS authentication |
step 1. Unauthorize supplicant interface
step 2. Start authentication on supplicant interface
step 3. Send invalid user certification during TLS exchange
step 4. Verify TLS server returns TLS Alert
step 5. Verify Backend returns an EAP-Failure
step 6. Send ping to remote host on WAN
step 7. Verify ping is not forwarded to WAN
References:
IETF RFC 2716 "PPP EAP TLS Authentication Protocol" Section 3.1: Overview of the EAP-TLS conversation
https://tools.ietf.org/html/rfc2716#section-3.1
| Test |
Module |
Name |
Synopsis |
Port becomes unauthorized if TLS session times out |
eap-tls.tcl |
cdrouter_eaptls_115 |
Port becomes unauthorized if TLS session times out |
step 1. Unauthorize supplicant interface
step 2. Start authentication on supplicant interface
step 3. Verify authentication succeeds
step 4. Restart authentication
step 5. Do not respond to TLS after receiving server certificate
step 6. Wait for all EAP TLS Requests to timeout
step 7. Verify port is not in unauthorized state
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.4.5: Connecting
https://standards.ieee.org/standard/802_1X-2001.html
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.7: Timeout
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
EAP-TLS authenticator/backend ignores duplicate EAP-TLS packets |
eap-tls.tcl |
cdrouter_eaptls_300 |
EAP-TLS authenticator/backend ignores duplicate EAP-TLS packets |
step 1. Configure supplicant to send duplicate EAP packets
step 2. Unauthorize supplicant interface
step 3. Start authentication on supplicant interface
step 4. Verify EAP-TLS authentication succeeds
References:
IETF RFC 2716 "PPP EAP TLS Authentication Protocol" Section 3.2: Retry behavior
https://tools.ietf.org/html/rfc2716#section-3.2
| Test |
Module |
Name |
Synopsis |
EAP-TLS authentication using small EAP Fragment sizes |
eap-tls.tcl |
cdrouter_eaptls_400 |
EAP-TLS authentication using small EAP Fragment sizes |
step 1. Unauthorize supplicant interface
step 2. Start authentication on supplicant interface
step 3. Set the EAP Fragment size to 10
step 4. Verify EAP-TLS Authentication succeeds
step 5. Repeat for EAP Fragment sizes 9,8,7,6
NOTE: Some Backend servers and internal authentication implementations will
timeout with small EAP Fragment sizes such as 1. With this size, the
authentication server is not able to read an entire EAP-TLS message before
the txWhen timer fires on the server. The server then restarts the TLS
session with a EAP Request/TLS-Start. This test starts with an EAP Fragment
size of 10 and attempts to lower the fragment size to 6 bytes.
References:
IETF RFC 2716 "PPP EAP TLS Authentication Protocol" Section 3.3: Fragmentation
https://tools.ietf.org/html/rfc2716#section-3.3
| Test |
Module |
Name |
Synopsis |
EAP-TLS backend accepts EAP packets without EAP-TLS Message Length field |
eap-tls.tcl |
cdrouter_eaptls_410 |
EAP-TLS backend accepts EAP packets without EAP-TLS Message Length field |
step 1. Unauthorize supplicant interface
step 2. Start authentication on supplicant interface
step 3. Configure supplicant to not send EAP-TLS message length for
EAP-TLS packets smaller than the EAP-TLS fragmentation setting
step 4. Wait for EAP-TLS Start
step 5. Send initial EAP-TLS packets without including message length
step 6. Verify EAP-TLS authentication succeeds
NOTE: For EAP-TLS packets that are less than the EAP fragment size, the
EAP-TLS Message Length field is optional.
References:
IETF RFC 2716 "PPP EAP TLS Authentication Protocol" Section 3.3: Fragmentation
https://tools.ietf.org/html/rfc2716#section-3.3
| Test |
Module |
Name |
Synopsis |
Authenticator handles EAP-TLS bad length DoS attack |
eap-tls.tcl |
cdrouter_eaptls_500 |
Authenticator handles EAP-TLS bad length DoS attack |
step 1. Unauthorize supplicant interface
step 2. Start authentication on supplicant interface
step 3. Wait for EAP Identity request
step 4. Respond with known identity
step 5. Wait for EAP-TLS Start Request
step 6. Respond with bad TLS message (Flags 0xc0 with no length or data)
step 7. Repeat for 10 EAP-TLS Start Requests
References:
IETF RFC 2716 "PPP EAP TLS Authentication Protocol" Section 3.3: Fragmentation
https://tools.ietf.org/html/rfc2716#section-3.3
IETF RFC 2716 "PPP EAP TLS Authentication Protocol" Section 4.3: EAP-TLS Response Packet
https://tools.ietf.org/html/rfc2716#section-4.3
eap-radius.tcl
RADIUS client tests for EAP based authentication (802.1X)
| Test |
Module |
Name |
Synopsis |
Verify authenticator sends EAP-Success after receiving Access-Accept |
eap-radius.tcl |
eapradius_1 |
Verify authenticator sends EAP-Success after receiving Access-Accept |
step 1. Unauthorize supplicant interface
step 2. Start authentication on supplicant interface
step 3. Wait for RADIUS packet sent to authentication server
step 4. Respond with Access-Accept message that includes an EAP-Success
packet as the EAP Message
step 5. Verify supplicant receives EAP-Success packet
Note: This test does use any specific type of EAP authentication. The RADIUS
server immediately returns an EAP-Success packet to the authenticator without
going through the request for a specific EAP type.
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.4: Response
https://standards.ieee.org/standard/802_1X-2001.html
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.5: Success
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Verify authenticator sends EAP-Failure after Access-Reject |
eap-radius.tcl |
eapradius_2 |
Verify authenticator sends EAP-Failure after Access-Reject |
step 1. Unauthorize supplicant interface
step 2. Start authentication on supplicant interface
step 3. Wait for RADIUS packet sent to authentication server
step 4. Respond with Access-Reject message that includes an EAP-Failure
packet as the EAP Message
step 5. Wait 60 seconds for supplicant to receive EAP Failure
Note: This test does use any specific type of EAP authentication. The RADIUS
server immediately returns an EAP-Failure packet to the authenticator without
going through the request for a specific EAP type.
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.4: Response
https://standards.ieee.org/standard/802_1X-2001.html
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.6: Fail
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Validate common RADIUS attributes sent from authenticator |
eap-radius.tcl |
eapradius_5 |
Validate common RADIUS attributes sent from authenticator |
step 1. Start authentication on supplicant interface
step 2. Wait for RADIUS packet sent to authentication server
step 3. Verify the Calling-Station-Id attribute is correct
step 4. Verify the Called-Station-Id attribute is present (WARNING only)
step 5. Verify the Message-Authenticator attribute is present
step 6. Verify the NAS-Identifier is present (WARNING only)
step 7. Verify the NAS-Port-Type is present (WARNING only)
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section D.3: RADIUS authentication
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Verify authentication fails if RADIUS secret is invalid |
eap-radius.tcl |
eapradius_6 |
Verify authentication fails if RADIUS secret is invalid |
step 1. Start authentication on supplicant interface
step 2. Configure RADIUS server to send packets with invalid RADIUS secret.
The Message-Authenticator attribute will still be calculated using
the original shared secret.
step 3. Verify authentication does not succeed
References:
IETF RFC 2138 "Remote Authentication Dial In User Service (RADIUS)" Section 2: Operation
https://tools.ietf.org/html/rfc2138#section-2
| Test |
Module |
Name |
Synopsis |
Verify authentication fails if Message-Authenticator attribute is invalid |
eap-radius.tcl |
eapradius_7 |
Verify authentication fails if Message-Authenticator attribute is invalid |
step 1. Start authentication on supplicant interface
step 2. Configure RADIUS server to send packets with invalid
Message-Authenticator attribute. The RADIUS authenticator
will still be calculated using the original shared secret.
step 3. Verify authentication does not succeed
References:
IETF RFC 2138 "Remote Authentication Dial In User Service (RADIUS)" Section 2: Operation
https://tools.ietf.org/html/rfc2138#section-2
| Test |
Module |
Name |
Synopsis |
Verify ID and authenticator are unique for each new Access-Request |
eap-radius.tcl |
eapradius_8 |
Verify ID and authenticator are unique for each new Access-Request |
step 1. Start authentication on supplicant interface
step 2. Save RADIUS request ID and request authenticator from each RADIUS
Access-Request packet
step 3. Verify authentication succeeds
step 4. Verify the ID in each RADIUS Request is unique
step 5. Verify the Request authenticator in also unique
References:
IETF RFC 2138 "Remote Authentication Dial In User Service (RADIUS)" Section 4.1: Access-Request
https://tools.ietf.org/html/rfc2138#section-4.1
| Test |
Module |
Name |
Synopsis |
Verify authenticator sends EAP-Failure when no response from RADIUS in unauthenticated state |
eap-radius.tcl |
eapradius_9 |
Verify authenticator sends EAP-Failure when no response from RADIUS in unauthenticated state |
step 1. Unauthorize supplicant interface
step 2. Start authentication on supplicant interface
step 3. Wait for RADIUS packet sent to authentication server
step 4. Do not response
step 5. Verify EAP-Failure is sent to supplicant
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.4: Response
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Verify authenticator can reassemble EAP packets from many RADIUS eapMessage attributes |
eap-radius.tcl |
eapradius_10 |
Verify authenticator can reassemble EAP packets from many RADIUS eapMessage attributes |
step 1. Start authentication on supplicant interface
step 2. Configure Authentication server to send 10 bytes of a
EAP message in each RADIUS eapMessage attribute resulting
in many EAP Message attributes in each RADIUS packet
step 3. Verify authentication succeeds
References:
IETF RFC 2869 "RADIUS Extensions" Section 5.13: EAP-Message
https://tools.ietf.org/html/rfc2869#section-5.13
| Test |
Module |
Name |
Synopsis |
Verify authenticator ignores RADIUS messages with invalid attribute list |
eap-radius.tcl |
eapradius_12 |
Verify authenticator ignores RADIUS messages with invalid attribute list |
step 1. Unauthorize supplicant interface
step 2. Start authentication on supplicant interface
step 3. Wait for RADIUS packet sent to authentication server
step 4. Respond with invalid attribute list containing bad eapMessage and
additional attribute with no length or data
step 5. Restart authentication on supplicant
step 6. Verify authentication succeeds
NOTE: This test verifies that the authenticator can recover after
it receives a RADIUS packet with a bad attribute list. Some devices
have experience a fault when they attempt to parse the bad
RADIUS attribute list.
References:
IETF RFC 2869 "RADIUS Extensions" Section 5.13: EAP-Message
https://tools.ietf.org/html/rfc2869#section-5.13
| Test |
Module |
Name |
Synopsis |
Verify authenticator ignores RADIUS messages without a Message-Authenticator attribute |
eap-radius.tcl |
eapradius_14 |
Verify authenticator ignores RADIUS messages without a Message-Authenticator attribute |
step 1. Start authentication on supplicant interface
step 2. Configure Authentication server so that the
Message-Authenticator attribute will not be sent in any
RADIUS replies
step 3. Verify authentication fails
NOTE: RFC 2869 recommends that the RADIUS client SHOULD silently
drop packets from the RADIUS server containing EAP-Message attribute
if the Message-Authenticator attribute is not included.
References:
IETF RFC 2869 "RADIUS Extensions" Section 5.13: EAP-Message
https://tools.ietf.org/html/rfc2869#section-5.13
| Test |
Module |
Name |
Synopsis |
Verify authenticator sends canned EAP-Failure message when Access-Reject is received |
eap-radius.tcl |
eapradius_20 |
Verify authenticator sends canned EAP-Failure message when Access-Reject is received |
step 1. Unauthorize supplicant interface
step 2. Start authentication on supplicant interface
step 3. Wait for RADIUS packet sent to authentication server
step 4. Respond with Access-Reject message that includes an EAP-Success
packet as the EAP Message
step 5. Verify supplicant receives EAP Failure
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section D.4: Security considerations
https://standards.ieee.org/standard/802_1X-2001.html
| Test |
Module |
Name |
Synopsis |
Verify authenticator sends canned EAP-Success message when Access-Accept is received |
eap-radius.tcl |
eapradius_21 |
Verify authenticator sends canned EAP-Success message when Access-Accept is received |
step 1. Unauthorize supplicant interface
step 2. Start authentication on supplicant interface
step 3. Wait for RADIUS packet sent to authentication server
step 4. Respond with Access-Accept message that includes an EAP-Failure
packet as the EAP Message
step 5. Verify supplicant receives EAP-Success
References:
IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section D.4: Security considerations
https://standards.ieee.org/standard/802_1X-2001.html
pppoe-pt.tcl
PPPoE pass through from PPPoE client on LAN to WAN side PPPoE server
| Test |
Module |
Name |
Synopsis |
Verify basic case of PPPoE pass through with LAN PPPoE client |
pppoe-pt.tcl |
cdrouter_pppoept_1 |
Verify basic case of PPPoE pass through with LAN PPPoE client |
step 1. Start a new PPPoE server on the WAN
step 2. Initiate a PPPoE client session from a host on the LAN
step 3. Verify the PPPoE client can establish a PPPoE session
step 4. Verify the PPPoE client can bring up the PPP link
step 5. Close the PPP and PPPoE session
NOTE: In order to pass this test, the device must support PPPoE
pass through for PPPoE clients on the LAN.
References:
IETF RFC 2516 "A Method for Transmitting PPP Over Ethernet (PPPoE)"
https://tools.ietf.org/html/rfc2516
| Test |
Module |
Name |
Synopsis |
Verify PPPoE packets to unknown MAC address do not use PPPoE pass through |
pppoe-pt.tcl |
cdrouter_pppoept_2 |
Verify PPPoE packets to unknown MAC address do not use PPPoE pass through |
step 1. Start a new PPPoE server on the WAN
step 2. Initiate a PPPoE client session from a host on the LAN
step 3. Verify the PPPoE client can establish a PPPoE session
step 4. Verify the PPPoE client can bring up the PPP link
step 5. Send PPPoE packet from WAN to LAN using an unknown MAC address
step 6. Verify the PPPoE packet is not forwarded onto the LAN
step 7. Close the PPP and PPPoE session for the existing PPPoE session
NOTE: In order to pass this test, the device must support PPPoE
pass through for PPPoE clients on the LAN.
References:
IETF RFC 2516 "A Method for Transmitting PPP Over Ethernet (PPPoE)"
https://tools.ietf.org/html/rfc2516
| Test |
Module |
Name |
Synopsis |
Verify basic case of PPPoE pass through with LAN PPPoE client using random session ID's |
pppoe-pt.tcl |
cdrouter_pppoept_3 |
Verify basic case of PPPoE pass through with LAN PPPoE client using random session ID’s |
step 1. Start a new PPPoE server on the WAN configured to use random session ID's
step 2. Initiate a PPPoE client session from a host on the LAN
step 3. Verify the PPPoE client can establish a PPPoE session
step 4. Verify the PPPoE client can bring up the PPP link
step 5. Close the PPP and PPPoE session
NOTE: In order to pass this test, the device must support PPPoE
pass through for PPPoE clients on the LAN.
References:
IETF RFC 2516 "A Method for Transmitting PPP Over Ethernet (PPPoE)"
https://tools.ietf.org/html/rfc2516
ipsec-esp.tcl
IPSEC ESP tests for IPSEC based VPNs
| Test |
Module |
Name |
Synopsis |
Verify the ESP header sequence number increases with each new IPv4 IPSEC ESP packet |
ipsec-esp.tcl |
cdrouter_esp_1 |
Verify the ESP header sequence number increases with each new IPv4 IPSEC ESP packet |
step 1. Initiate 100 outbound ICMP Echo Requests to the remote VPN host
step 2. Outbound traffic should be sent through IPSEC tunnel
step 3. Verify the sequence number in the IPSEC ESP header increments by 1
References:
IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 2.2: Sequence Number
https://tools.ietf.org/html/rfc2406#section-2.2
| Test |
Module |
Name |
Synopsis |
Verify manual IPSEC keys continue to work after ESP sequence number wraps |
ipsec-esp.tcl |
cdrouter_esp_3 |
Verify manual IPSEC keys continue to work after ESP sequence number wraps |
step 1. Set the current sequence number for the outbound SA to 0xfffffffe
step 2. Initiate 10 outbound ICMP Echo Requests to the remote VPN host
step 3. Outbound traffic should be sent through IPSEC tunnel
step 4. Verify all packets are received as IPSEC ESP sequence number wraps
References:
IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 5: Conformance Requirements
https://tools.ietf.org/html/rfc2406#section-5
| Test |
Module |
Name |
Synopsis |
Verify no anti-relay techniques are used with manual IPSEC keys |
ipsec-esp.tcl |
cdrouter_esp_5 |
Verify no anti-relay techniques are used with manual IPSEC keys |
step 1. Initiate 10 outbound ICMP Echo Requests to the remote host
step 2. Before each packet is sent, reset the ESP sequence number
to 11221122 so that all outbound packets have the same
sequence number.
step 3. Outbound traffic should be sent through IPSEC tunnel
step 4. Verify all packets are sent and received with no errors
References:
IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 5: Conformance Requirements
https://tools.ietf.org/html/rfc2406#section-5
| Test |
Module |
Name |
Synopsis |
Verify inner IPv4 TTL is decremented for IPSEC tunneled packet |
ipsec-esp.tcl |
cdrouter_esp_8 |
Verify inner IPv4 TTL is decremented for IPSEC tunneled packet |
step 1. Forward an IP packet from a LAN client to the WAN
step 2. Verify the TTL of the tunneled packet is decremented by 1
References:
IETF RFC 2401 "Security Architecture for the Internet Protocol" Section 5.1.2: Header Construction for Tunnel Mode
https://tools.ietf.org/html/rfc2401#section-5.1.2
| Test |
Module |
Name |
Synopsis |
Verify packets with wrong ESP authentication are dropped |
ipsec-esp.tcl |
cdrouter_esp_10 |
Verify packets with wrong ESP authentication are dropped |
step 1. Initiate an outbound ICMP Echo Request to a WAN destination
step 2. Verify ICMP Echo Reply is received
step 3. Configure outbound SA with invalid authentication key
step 4. Repeat outbound ICMP Echo Request
step 5. Verify return ICMP Echo Reply is dropped
step 6. Reconfigure original ESP authentication key
step 7. Verify outbound ICMP Echo Request now succeeds
NOTE: This test is only run when the configured IPSEC tunnel has
authentication enabled.
References:
IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 3.4.5: Packet Decryption
https://tools.ietf.org/html/rfc2406#section-3.4.5
| Test |
Module |
Name |
Synopsis |
Verify Incoming IP fragments for ESP tunnel are reassembled |
ipsec-esp.tcl |
cdrouter_esp_20 |
Verify Incoming IP fragments for ESP tunnel are reassembled |
step 1. Set the MTU on the IPSEC tunnel endpoint to 108
step 2. Send a 1000 byte UDP packet from the LAN to the WAN
step 3. Send a return 1000 byte UDP packet from the WAN to the LAN
over the IPSEC tunnel. The IPSEC packet will be fragmented
based on the MTU size.
step 4. Verify router reassembled all IP fragments and forwards UDP
packet to the LAN host
step 5. Add 8 to the MTU size and repeat the test until the MTU is 996
References:
IETF RFC 791 "INTERNET PROTOCOL" Section 3.2: Fragmentation and Reassembly
https://tools.ietf.org/html/rfc791#section-3.2
IETF RFC 2401 "Security Architecture for the Internet Protocol" Section 5.2: Processing Inbound IP Traffic
https://tools.ietf.org/html/rfc2401#section-5.2
IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 3.1: ESP Header Location
https://tools.ietf.org/html/rfc2406#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify out-of-order IP fragments for ESP tunnel are reassembled |
ipsec-esp.tcl |
cdrouter_esp_21 |
Verify out-of-order IP fragments for ESP tunnel are reassembled |
step 1. Set the MTU on the IPSEC tunnel endpoint to 108
step 2. Send a 1000 byte UDP packet from the LAN to the WAN
step 3. Send a return 1000 byte UDP packet from the WAN to the LAN
over the IPSEC tunnel using out of order IP fragments
step 4. Verify router reassembled all out-of-order IP fragments
and forwards UDP packet to the LAN host
References:
IETF RFC 791 "INTERNET PROTOCOL" Section 3.2: Fragmentation and Reassembly
https://tools.ietf.org/html/rfc791#section-3.2
IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 3.1: ESP Header Location
https://tools.ietf.org/html/rfc2406#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify router fragments large IP packets before sending over IPSEC tunnel |
ipsec-esp.tcl |
cdrouter_esp_22 |
Verify router fragments large IP packets before sending over IPSEC tunnel |
step 1. Forward UDP packet from LAN host to WAN using 1500 byte packet
step 2. Verify packet is forwarded over IPSEC tunnel
step 3. In order to forward the packet over the tunnel, the router must
fragment the packet.
step 4. Send a return UDP packet with the same packet size from the WAN
to the LAN.
step 5. Reduce the packet size by 1 byte and repeat until the packet size
is >= 1408.
NOTE: The router may fragment the inner IP packet before ESP encapsulation
and send 2 or more ESP packets or the router may fragment the outer ESP
packet and send IP fragments. The first approach is more NAT friendly since
IP fragments are not used and this allows other NAT routers in the path
to use SPI tracking for IPSEC pass through connections. This test case
supports both implementations.
References:
IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 3.3.5: Fragmentation
https://tools.ietf.org/html/rfc2406#section-3.3.5
| Test |
Module |
Name |
Synopsis |
Verify router supports PMTU discovery for packets sent over IPSEC tunnel |
ipsec-esp.tcl |
cdrouter_esp_100 |
Verify router supports PMTU discovery for packets sent over IPSEC tunnel |
step 1. Send 1500 byte UDP packet with IP Don't Fragment Flag = 1 to the
remoteVpn host over the IPSEC tunnel
step 2. Check for an ICMP Destination Unreachable packet with code = 4
step 3. Repeat process two more times until until an ICMP Destination
Unreachable is received, or all 3 packets are sent
step 4. If an ICMP Destination Unreachable was sent, verify the
the code value is 4 and verify MTU value in the ICMP header
step 5. Reduce the UDP packet size by 1 byte and repeat the process
until no ICMP Destination Unreachable is sent
step 6. When a packet size is found that does not generate an
ICMP Destination Unreachable, verify packets can be forwarded over
IPSEC tunnel using this packet size
step 7. Verify the final MTU size is the same as the MTU size
reported in the ICMP Destination Unreachable packet
NOTE: Some devices rate limit the number of ICMP packets that may be sent.
This test will sent 3 UDP packets over a 15 second window in order to
generate an ICMP unreachable packet. If your device uses rate limiting on
ICMP packets, it must allow at least 1 ICMP packet every 10 seconds.
References:
IETF RFC 2401 "Security Architecture for the Internet Protocol" Section 6.1: PMTU/DF Processing
https://tools.ietf.org/html/rfc2401#section-6.1
IETF RFC 1191 "Path MTU Discovery"
https://tools.ietf.org/html/rfc1191
| Test |
Module |
Name |
Synopsis |
Verify DF bit from original packet is copied to encapsulation header |
ipsec-esp.tcl |
cdrouter_esp_101 |
Verify DF bit from original packet is copied to encapsulation header |
step 1. Send ICMP Echo packet to the remoteVpn with the DF flag set to 1
step 2. Wait for ESP packet on the WAN for this IPSEC tunnel
step 3. Verify the DF flag in the ESP header is 1
NOTE: In order to pass this test, the router may need to configure the
treatment of the DF bit. The router should be configured to copy the value
of the DF bit from the inner IP packet. This allows the PMTU behavior to
work for packets that have been tunneled.
References:
IETF RFC 2401 "Security Architecture for the Internet Protocol" Section 6.1: PMTU/DF Processing
https://tools.ietf.org/html/rfc2401#section-6.1
| Test |
Module |
Name |
Synopsis |
Verify return traffic that does not use IPSEC/ESP is dropped |
ipsec-esp.tcl |
cdrouter_esp_200 |
Verify return traffic that does not use IPSEC/ESP is dropped |
step 1. Forward UDP packet from LAN to remote VPN host
step 2. Verify packet is forwarded over IPSEC tunnel to remote VPN host
step 3. Send a return UDP packet from the remote VPN host without
encapsulating the packet with an ESP header
step 4. Verify the packet is not forwarded back to the LAN
References:
IETF RFC 2401 "Security Architecture for the Internet Protocol" Section 4.4.1: The Security Policy Database (SPD)
https://tools.ietf.org/html/rfc2401#section-4.4.1
| Test |
Module |
Name |
Synopsis |
Verify all configured IPv4 IPSEC tunnels are operational |
ipsec-esp.tcl |
cdrouter_esp_400 |
Verify all configured IPv4 IPSEC tunnels are operational |
step 1. Configure SAs for all IPSEC tunnels defined in the configuration file
step 2. For each tunnel, verify a TCP connection can be established
from the LAN host to a remote host over the IPSEC tunnel
step 3. Close all TCP connections
dmz.tcl
Test cases for DMZ configurations
| Test |
Module |
Name |
Synopsis |
Inbound TCP connections to public side HTTP port are forwarded to DMZ host |
dmz.tcl |
cdrouter_dmz_1 |
Inbound TCP connections to public side HTTP port are forwarded to DMZ host |
step 1. Ping the router's LAN IP address from the DMZ host
step 2. Initiate a WAN TCP connection to the router's public IP at port 80
step 3. Verify the connection is forwarded to the DMZ host
step 4. Initiate a WAN TCP connection to the router's private IP at port 80
step 5. Verify the connection is not established
| Test |
Module |
Name |
Synopsis |
Inbound TCP packets are sent to DMZ host for all ports |
dmz.tcl |
cdrouter_dmz_100 |
Inbound TCP packets are sent to DMZ host for all ports |
step 1. Ping the router's LAN IP address from the DMZ host
step 2. Send TCP SYN packets from WAN to each port in the port scan range
step 3. Verify packets are forwarded to DMZ host
step 4. Do not test ports that have port forwarding configured
NOTE: The port scan range can be configured using the 'portScanStart' and
'portScanStop' testvars. You can also specify any exceptions to the port
range using the testvar 'lanDmzTcpPortExceptions'.
Example:
testvar portScanStart 0
testvar portScanStop 65535
| Test |
Module |
Name |
Synopsis |
Inbound UDP packets are sent to DMZ host for all ports |
dmz.tcl |
cdrouter_dmz_101 |
Inbound UDP packets are sent to DMZ host for all ports |
step 1. Ping the router's LAN IP address from the DMZ host
step 2. Send UDP packets from WAN to each port in the port scan range
step 3. Verify packets are forwarded to DMZ host
step 4. Do not test ports that have port forwarding configured
NOTE: The port scan range can be configured using the 'portScanStart' and
'portScanStop' testvars. You can also specify any exceptions to the port
range using the testvar 'lanDmzUdpPortExceptions'.
Example:
testvar portScanStart 0
testvar portScanStop 65535
| Test |
Module |
Name |
Synopsis |
ICMP Echo packets are forwarded to DMZ host |
dmz.tcl |
cdrouter_dmz_110 |
ICMP Echo packets are forwarded to DMZ host |
step 1. Initiate an inbound ICMP Echo Request from the WAN to router's public IP
step 2. Verify ICMP Echo Request is received by DMZ host
NOTE: Some routers do not support sending unassociated ICMP packets to
the DMZ host. Instead, they may locally process the ICMP packet or drop the
packet. If the router does not support this functionality, the
'lanDmzSupportsIcmp' testvar should be set to no.
Example:
testvar lanDmzSupportsIcmp no
| Test |
Module |
Name |
Synopsis |
Non ICMP, TCP, UDP, or SCTP protocol types are forwarded to DMZ host |
dmz.tcl |
cdrouter_dmz_200 |
Non ICMP, TCP, UDP, or SCTP protocol types are forwarded to DMZ host |
step 1. Send packet with IP protocol type 0 from WAN to router's public IP
step 2. Verify IP packet is forwarded to DMZ host
step 3. Repeat for IP protocol types up to 255, skipping protocol types 1
(ICMP), 6 (TCP), 17 (UDP), and 132 (SCTP) which are all transport
protocols
step 4. Verify each protocol type is forwarded to the DMZ host
NOTE: The DMZ may not forward certain protocols that may be terminated
locally on the router. For example, it may not be possible to have IGMP
packets pass through the DMZ. You may configure a list of specific IP
protocol types that should be skipped for this test using the testvar
'lanDmzIpProtoExceptions'. This list should contain a comma separated
list of ports.
For example:
testvar lanDmzIpProtoExceptions "2,47"
mcast.tcl
IGMPv2/v3 and multicast data tests for IGMP proxy or pass through
| Test |
Module |
Name |
Synopsis |
IGMP packets from LAN are forwarded/proxied to WAN interface |
mcast.tcl |
cdrouter_mcast_1 |
IGMP packets from LAN are forwarded/proxied to WAN interface |
step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
step 2. Send an IGMPv2/3 Membership Report packet on the LAN interface
step 3. Verify an IGMPv2/3 Membership Report packet is received on the WAN interface
step 4. For IGMPv3, verify group record is CHANGE_TO_EXCLUDE_MODE for the group
with an empty source list.
step 5. Repeat test using an IGMPv2 Leave packet or IGMPv3 Memebership Report
to leave the multicast group
step 6. For IGMPv3, verify group record is CHANGE_TO_INCLUDE_MODE for the group
with an empty source list.
NOTE: This test will work with either a multicast pass through implementation
or a multicast proxy implementation.
NOTE: Some routers may send an IGMP query on the LAN interface after the
IGMP Leave from the LAN client. The IGMP Leave may not be sent on the
WAN interface until the LAN side has made multiple queries.
The amount of time this test case should wait before expecting the
IGMP Leave on the WAN interface may be configured by setting the
testvar 'multicastCacheTimeout'.
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
| Test |
Module |
Name |
Synopsis |
Verify IPv4 TTL is decremented for multicast packets |
mcast.tcl |
cdrouter_mcast_2 |
Verify IPv4 TTL is decremented for multicast packets |
step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
step 2. Join a multicast group on the LAN interface
step 3. Send a UDP packet to the multicast group from the WAN
step 4. Verify the multicast packet is received on the LAN
step 5. Verify the TTL is decremented by the expected IP hop count
NOTE: This test will work with either a multicast pass through implementation
or a multicast proxy implementation.
NOTE: The number of expected IP hops can be configured using the testvar
'IPv4HopCount'. The default is 1 IP hop. If the device is using bridge
mode, the expected IPv4HopCount is 0.
NOTE: The testvar multicastJoinDelay can be used to control how long
the test waits to verify the multicast traffic after receiving the
IGMP report. The default value is 2 seconds.
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
| Test |
Module |
Name |
Synopsis |
Forward Multicast UDP packets with various packet lengths (LAN to WAN) |
mcast.tcl |
cdrouter_mcast_11 |
Forward Multicast UDP packets with various packet lengths (LAN to WAN) |
step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
step 2. Join a multicast group on the WAN interface
step 3. Forward a multicast UDP packet from the LAN with UDP length 4
step 4. Verify the packet is received on the WAN interface
step 5. Repeat for all packet sizes up to the max MTU
NOTE: This test will work with either a multicast pass through implementation
or a multicast proxy implementation.
NOTE: The testvar multicastJoinDelay can be used to control how long
the test waits to verify the multicast traffic after receiving the
IGMP report. The default value is 2 seconds.
NOTE: If the device does not support forwarding multiast traffic
through NAT to the WAN, this test case may be skipped by setting
the testvar supportsMulticastOut to no.
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
| Test |
Module |
Name |
Synopsis |
Forward Multicast UDP packets with various packet lengths (WAN to LAN) |
mcast.tcl |
cdrouter_mcast_12 |
Forward Multicast UDP packets with various packet lengths (WAN to LAN) |
step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
step 2. Join a multicast group on the LAN interface
step 3. Forward a multicast UDP packet from the WAN with UDP length 4
step 4. Verify the packet is received on the LAN interface
step 5. Repeat for all packet sizes up to the max MTU
NOTE: This test will work with either a multicast pass through implementation
or a multicast proxy implementation.
NOTE: The testvar multicastJoinDelay can be used to control how long
the test waits to verify the multicast traffic after receiving the
IGMP report. The default value is 2 seconds.
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
| Test |
Module |
Name |
Synopsis |
Verify IGMP router periodically sends general IGMP Query on LAN interface |
mcast.tcl |
cdrouter_mcast_20 |
Verify IGMP router periodically sends general IGMP Query on LAN interface |
step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
step 2. Wait up to igmpQueryInterval seconds for a general IGMP Query on the LAN
step 3. Repeat for 2 queries
NOTE: This test will work with a multicast proxy implementation only.
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
| Test |
Module |
Name |
Synopsis |
Multicast streams are not forwarded if no group members exist |
mcast.tcl |
cdrouter_mcast_50 |
Multicast streams are not forwarded if no group members exist |
step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
step 2. Allocate a multicast group that has no members on the LAN
step 3. Forward UDP multicast packet from WAN to LAN using group
step 4. Verify the packet is not received on the LAN
NOTE: This test will work with a multicast proxy implementation only.
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
| Test |
Module |
Name |
Synopsis |
Multicast streams are not forwarded after last member leaves group |
mcast.tcl |
cdrouter_mcast_51 |
Multicast streams are not forwarded after last member leaves group |
step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
step 2. Join a multicast group on the LAN interface
step 3. Send a UDP packet to the multicast group from the WAN
step 4. Verify the multicast packet is received on the LAN
step 5. Send a IGMP Leave packet on the LAN interface for group
step 6. Wait for the multicast cache to expire
step 7. Forward UDP multicast packet from WAN to LAN using group
step 8. Verify the packet is not received on the LAN
NOTE: This test will work with a multicast proxy implementation only.
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
| Test |
Module |
Name |
Synopsis |
Multicast streams are not forwarded after last member ages out |
mcast.tcl |
cdrouter_mcast_52 |
Multicast streams are not forwarded after last member ages out |
step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
step 2. Join a multicast group on the LAN interface
step 3. Send a UDP packet to the multicast group from the WAN
step 4. Verify the multicast packet is received on the LAN
step 5. Wait for the multicast group to expire
step 6. Forward UDP multicast packet from WAN to LAN using group
step 7. Verify the packet is not received on the LAN
NOTE: This test will work with a multicast proxy implementation only.
NOTE: The amount of time it takes the multicast group to expire is
based on the igmpQueryInterval, igmpRobustnessVariable, and
igmpQueryResponseInterval. These can all be configured using the
following testvars:
testvar igmpQueryInterval 125
testvar igmpRobustnessVariable 2
testvar igmpQueryResponseInterval 10
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
| Test |
Module |
Name |
Synopsis |
IGMP proxy interface answers IGMP general query requests |
mcast.tcl |
cdrouter_mcast_53 |
IGMP proxy interface answers IGMP general query requests |
step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
step 2. Join a multicast group on the LAN interface
step 3. Wait up to 20 seconds for IGMP membership report on the WAN
step 4. Issue an IGMP Membership query to 224.0.0.1 on WAN for group address 0.0.0.0
step 5. Verify router's WAN side responds with IGMP membership report for
the multicast group
NOTE: This test will work with a multicast proxy implementation only.
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
| Test |
Module |
Name |
Synopsis |
IGMP proxy interface answers IGMP specific query requests |
mcast.tcl |
cdrouter_mcast_54 |
IGMP proxy interface answers IGMP specific query requests |
step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
step 2. Join a multicast group on the LAN interface
step 3. Wait up to 20 seconds for IGMP membership report on the WAN
step 4. Issue an IGMP Membership query to 224.0.0.1 on WAN for specific group address
step 5. Verify router's WAN side responds with IGMP membership report for
the multicast group
NOTE: This test will work with a multicast proxy implementation only.
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
| Test |
Module |
Name |
Synopsis |
Verify IGMP router sends IGMP Group Specific Query after last member leaves group |
mcast.tcl |
cdrouter_mcast_60 |
Verify IGMP router sends IGMP Group Specific Query after last member leaves group |
step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
step 2. Send an IGMPv2/3 Membership Report packet on the LAN interface
step 3. Send an IGMPv2 Leave or IGMPv3 Memebership packet on the LAN interface
to leave the multicast group
step 4. Verify an IGMPv2/3 Query packet is sent on the LAN interface
to the specific multicast group. If igmpFastLeave is set
to yes, verify that no IGMP Query is sent.
NOTE: This test will work with a multicast proxy implementation only.
NOTE: If the device supports IGMP Fast Leave, the testvar igmpFastLeave
should be set to yes. In this case, the test case will verify that
no group specific IGMP query is sent after the IGMP Leave.
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
| Test |
Module |
Name |
Synopsis |
Verify IGMP router sends IGMP Leave after last group member ages out |
mcast.tcl |
cdrouter_mcast_70 |
Verify IGMP router sends IGMP Leave after last group member ages out |
step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
step 2. Send an IGMPv2/3 Membership Report packet on the LAN interface
step 3. Verify an IGMPv2/3 Membership Report packet is received on the WAN interface
step 4. For IGMPv3, verify group record is CHANGE_TO_EXCLUDE_MODE for the group
with an empty source list.
step 5. Let group member on the LAN age out. No responses will sent to IGMP
queries and no IGMP Leave will be sent.
step 6. Verify IGMP leave or IGMPv3 membership report is received for the group
on the WAN interface
step 7. For IGMPv3, verify group record is CHANGE_TO_INCLUDE_MODE for the group
with an empty source list.
NOTE: This test will work with either a multicast pass through implementation
or a multicast proxy implementation.
NOTE: The amount of time it takes the multicast group to expire is
based on the igmpQueryInterval, igmpRobustnessVariable, and
igmpQueryResponseInterval. These can all be configured using the
following testvars:
testvar igmpQueryInterval 125
testvar igmpRobustnessVariable 2
testvar igmpQueryResponseInterval 10
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
| Test |
Module |
Name |
Synopsis |
Verify IGMP router accepts reports with unspecified source address |
mcast.tcl |
cdrouter_mcast_80 |
Verify IGMP router accepts reports with unspecified source address |
step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
step 2. Send an IGMPv2/3 Membership Report packet on the LAN interface using
the unspecified src address 0.0.0.0.
step 3. Verify an IGMPv2/3 Membership Report packet is received on the WAN interface
step 4. For IGMPv3, verify group record is CHANGE_TO_EXCLUDE_MODE for the group
with an empty source list.
step 5. Repeat test using an IGMPv2 Leave packet or IGMPv3 Memebership Report
to leave the multicast group
step 6. For IGMPv3, verify group record is CHANGE_TO_INCLUDE_MODE for the group
with an empty source list.
NOTE: This test will work with either a multicast pass through implementation
or a multicast proxy implementation.
NOTE: Some routers may send an IGMP query on the LAN interface after the
IGMP Leave from the LAN client. The IGMP Leave may not be sent on the
WAN interface until the LAN side has made multiple queries.
The amount of time this test case should wait before expecting the
IGMP Leave on the WAN interface may be configured by setting the
testvar 'multicastCacheTimeout'.
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
IETF RFC 4541 "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches"
https://tools.ietf.org/html/rfc4541
| Test |
Module |
Name |
Synopsis |
Verify IGMP snooping switch scenario with unspecified source address |
mcast.tcl |
cdrouter_mcast_81 |
Verify IGMP snooping switch scenario with unspecified source address |
step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
step 2. Join a multicast group on the LAN interface using src address 0.0.0.0
step 3. Send a UDP packet to the multicast group from the WAN
step 4. Verify the multicast packet is received on the LAN
step 5. Verify the TTL is decremented by the expected IP hop count
NOTE: This test will work with either a multicast pass through implementation
or a multicast proxy implementation.
NOTE: The number of expected IP hops can be configured using the testvar
'IPv4HopCount'. The default is 1 IP hop.
NOTE: The testvar multicastJoinDelay can be used to control how long
the test waits to verify the multicast traffic after receiving the
IGMP report. The default value is 2 seconds.
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
IETF RFC 4541 "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches"
https://tools.ietf.org/html/rfc4541
| Test |
Module |
Name |
Synopsis |
Verify IGMP proxy interface answers general IGMP query requests with unspecified source address |
mcast.tcl |
cdrouter_mcast_82 |
Verify IGMP proxy interface answers general IGMP query requests with unspecified source address |
step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
step 2. Join a multicast group on the LAN interface
step 3. Wait up to 20 seconds for IGMP membership report on the WAN
step 4. Issue an IGMP Membership query to 224.0.0.1 on WAN for group address 0.0.0.0
using src address 0.0.0.0
step 5. Verify router's WAN side responds with IGMP membership report for
the multicast group
NOTE: This test will work with a multicast proxy implementation only.
An IGMP snooping switch may send an IGMP query with a 0.0.0.0 IP Source Address.
IGMP does not specifically prevent IGMP queries using an unspecified
src address while RFC 3590 does not allow this for MLD.
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
IETF RFC 4541 "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches"
https://tools.ietf.org/html/rfc4541
| Test |
Module |
Name |
Synopsis |
Verify IGMP proxy interface answers specific IGMP query requests with unspecified source address |
mcast.tcl |
cdrouter_mcast_83 |
Verify IGMP proxy interface answers specific IGMP query requests with unspecified source address |
step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
step 2. Join a multicast group on the LAN interface
step 3. Wait up to 20 seconds for IGMP membership report on the WAN
step 4. Issue an IGMP Membership query to 224.0.0.1 on WAN for specific group address
using src address 0.0.0.0
step 5. Verify router's WAN side responds with IGMP membership report for
the multicast group
NOTE: This test will work with a multicast proxy implementation only.
An IGMP snooping switch may send an IGMP query with a 0.0.0.0 IP Source Address.
IGMP does not specifically prevent IGMP queries using an unspecified
src address while RFC 3590 does not allow this for MLD.
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
IETF RFC 4541 "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches"
https://tools.ietf.org/html/rfc4541
| Test |
Module |
Name |
Synopsis |
Verify the maximum number of multicast groups received on the LAN |
mcast.tcl |
cdrouter_mcast_100 |
Verify the maximum number of multicast groups received on the LAN |
step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
step 2. Join igmpMaxGroups multicast groups on the LAN interface
step 3. Forward a multicast UDP packet from the WAN to each group
step 4. Verify each group is received on the LAN interface
step 5. Send a IGMP Leave for each multicast group
NOTE: This test will work with either a multicast pass through implementation
or a multicast proxy implementation.
NOTE: You can slow down the rate at which CDRouter will join each group
by configuring the testvar multicastScaleDelay. It defaults to 1
millisecond.
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
| Test |
Module |
Name |
Synopsis |
Verify IPTV channel change test scenario 1 (no overlap) |
mcast.tcl |
cdrouter_mcast_110 |
Verify IPTV channel change test scenario 1 (no overlap) |
step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
step 2. Check the testvar iptvChannelRange to determine the number of channels
step 3. For each channel, join the multicast group on the LAN
step 4. Verify the IGMPv2 or IGMPv3 report is received in the WAN
step 5. Start sending multicast data on the WAN for the new group
step 6. Verify the LAN side starts to receive the multicast data
step 7. Wait for a small delay determined by testvar iptvChannelChangeDelay
step 8. Leave the multicast group on the LAN using IGMPv2/3
step 9. Switch to the next channel or exit if too many failures have
occurred
NOTE: There are a few test variables that can control the number of channels
and speed of this test.
The testvar iptvChannelChangeDelay specifies a delay in milliseconds to wait
between each channel change.
The testvar iptvChannelRange specifies the total number of channel changes to
attempt.
The testvar iptvMaxFailures is used to stop the test after a specific number
of failures. When testing a large number of channels, it can be useful
to stop the test early if many channels start failing.
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
| Test |
Module |
Name |
Synopsis |
Verify IPTV channel change test scenario 2 (overlap) |
mcast.tcl |
cdrouter_mcast_120 |
Verify IPTV channel change test scenario 2 (overlap) |
step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
step 2. Check the testvar iptvChannelRange to determine the number of channels
step 3. For each channel, join the multicast group on the LAN
step 4. Verify the IGMPv2 or IGMPv3 report is received in the WAN
step 5. Leave any previous multicast group for the last channel
step 6. Start sending multicast data on the WAN for the new group
step 7. Verify the LAN side starts to receive the multicast data
step 8. Wait for a small delay determined by testvar iptvChannelChangeDelay
step 9. Switch to the next channel or exit if too many failures have
occurred
NOTE: There are a few test variables that can control the number of channels
and speed of this test.
The testvar iptvChannelChangeDelay specifies a delay in milliseconds to wait
between each channel change.
The testvar iptvChannelRange specifies the total number of channel changes to
attempt.
The testvar iptvMaxFailures is used to stop the test after a specific number
of failures. When testing a large number of channels, it can be useful
to stop the test early if many channels start failing.
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
| Test |
Module |
Name |
Synopsis |
Verify IGMPv3 membership with source specific ALLOW_NEW_SOURCES/BLOCK_OLD_SOURCES |
mcast.tcl |
cdrouter_mcast_200 |
Verify IGMPv3 membership with source specific ALLOW_NEW_SOURCES/BLOCK_OLD_SOURCES |
step 1. Send an IGMPv3 Query on the WAN to allow device to detect IGMP version
step 2. Send an IGMPv3 Membership Report packet on the LAN interface
with ALLOW_NEW_SOURCES record containing specific source
step 3. Verify an IGMPv3 Membership Report packet is received on the WAN interface
step 4. Verify group record is ALLOW_NEW_SOURCES for the group
with a matching source list.
step 5. Verify multicast forwarding from WAN to LAN for new group using
the specific source address.
step 6. Continue test using an IGMPv3 BLOCK_OLD_SOURCES to leave the multicast group
step 7. Verify group record is BLOCK_OLD_SOURCES for the group
with a matching source list.
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
| Test |
Module |
Name |
Synopsis |
Verify IGMPv3 router blocks incoming multicast sources that do not match the source list |
mcast.tcl |
cdrouter_mcast_210 |
Verify IGMPv3 router blocks incoming multicast sources that do not match the source list |
step 1. Send an IGMPv3 Query on the WAN to allow device to detect IGMP version
step 2. Send an IGMPv3 Membership Report packet on the LAN interface
with ALLOW_NEW_SOURCES record containing specific source
step 3. Verify an IGMPv3 Membership Report packet is received on the WAN interface
step 4. Verify group record is ALLOW_NEW_SOURCES for the group
with a matching source list.
step 5. Verify multicast forwarding fails from WAN to LAN for new group using
the different source address.
step 6. Continue test using an IGMPv3 BLOCK_OLD_SOURCES to leave the multicast group
step 7. Verify group record is BLOCK_OLD_SOURCES for the group
with a matching source list.
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
| Test |
Module |
Name |
Synopsis |
Verify IGMPv3 router blocks incoming sources on a per group basis |
mcast.tcl |
cdrouter_mcast_220 |
Verify IGMPv3 router blocks incoming sources on a per group basis |
step 1. Send an IGMPv3 Query on the WAN to allow device to detect IGMP version
step 2. Send an IGMPv3 Membership Report packet on the LAN interface
with ALLOW_NEW_SOURCES record containing specific source
step 3. Verify an IGMPv3 Membership Report packet is received on the WAN interface
step 4. Verify group record is ALLOW_NEW_SOURCES for the group
with a matching source list.
step 5. Verify multicast forwarding from WAN to LAN for new group using
the specific source address.
step 6. Verify multicast forwarding fails from WAN to LAN for a different group
using the same specific source address.
step 7. Continue test using an IGMPv3 BLOCK_OLD_SOURCES to leave the multicast group
step 8. Verify group record is BLOCK_OLD_SOURCES for the group
with a matching source list.
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
| Test |
Module |
Name |
Synopsis |
Verify IGMPv3 source specific group with multiple sources |
mcast.tcl |
cdrouter_mcast_230 |
Verify IGMPv3 source specific group with multiple sources |
step 1. Send an IGMPv3 Query on the WAN to allow device to detect IGMP version
step 2. Create a new server on the WAN for a multicast source
step 3. Send an IGMPv3 Membership Report packet on the LAN interface
with ALLOW_NEW_SOURCES record containing multiple specific sources
step 4. Verify an IGMPv3 Membership Report packet is received on the WAN interface
step 5. Verify group record is ALLOW_NEW_SOURCES for the group
with a matching source list.
step 6. Verify multicast forwarding from WAN to LAN for new group using
the specific source address from source address 1.
step 7. Verify multicast forwarding from WAN to LAN for new group using
the specific source address from source address 2.
step 8. Continue test using an IGMPv3 BLOCK_OLD_SOURCES to leave the multicast group
step 9. Verify group record is BLOCK_OLD_SOURCES for the group
with a matching source list.
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
| Test |
Module |
Name |
Synopsis |
Verify IGMPv3 general query requests with source specific memberships |
mcast.tcl |
cdrouter_mcast_240 |
Verify IGMPv3 general query requests with source specific memberships |
step 1. Send an IGMPv3 Query on the WAN to allow device to detect IGMP version
step 2. Join a multicast group on the LAN interface
step 3. Wait up to 20 seconds for IGMP membership report on the WAN
step 4. Issue an IGMP Membership query to 224.0.0.1 on WAN for group 0.0.0.0
step 5. Verify router's WAN side responds with IGMP membership report for
the multicast group
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
| Test |
Module |
Name |
Synopsis |
Verify IGMPv3 specific query requests with source specific memberships |
mcast.tcl |
cdrouter_mcast_250 |
Verify IGMPv3 specific query requests with source specific memberships |
step 1. Send an IGMPv3 Query on the WAN to allow device to detect IGMP version
step 2. Join a multicast group on the LAN interface
step 3. Wait up to 20 seconds for IGMP membership report on the WAN
step 4. Issue an IGMP Membership query on WAN for specific group address
step 5. Verify router's WAN side responds with IGMP membership report for
the multicast group
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
| Test |
Module |
Name |
Synopsis |
Verify IGMPv3 group and source specific query requests |
mcast.tcl |
cdrouter_mcast_260 |
Verify IGMPv3 group and source specific query requests |
step 1. Send an IGMPv3 Query on the WAN to allow device to detect IGMP version
step 1. Join a multicast group on the LAN interface
step 2. Wait up to 20 seconds for IGMP membership report on the WAN
step 3. Issue an IGMP Membership query on WAN for specific group address
step 4. Verify router's WAN side responds with IGMP membership report for
the multicast group
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
| Test |
Module |
Name |
Synopsis |
Verify IGMPv3 maximum number of multicast groups with multiple group records |
mcast.tcl |
cdrouter_mcast_300 |
Verify IGMPv3 maximum number of multicast groups with multiple group records |
step 1. Send an IGMPv3 Query on the WAN to allow device to detect IGMP version
step 2. Join igmpMaxGroups multicast groups on the LAN interface using
multiple group records in a single IGMPv3 membership report
step 3. Forward a multicast UDP packet from the WAN to each group
step 4. Verify each group is received on the LAN interface
step 5. Send a IGMP Leave for each multicast group
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
| Test |
Module |
Name |
Synopsis |
Verify IGMPv3 source specific IPTV channel change test scenario |
mcast.tcl |
cdrouter_mcast_310 |
Verify IGMPv3 source specific IPTV channel change test scenario |
step 1. Send an IGMPv3 Query on the WAN to allow device to detect IGMP version
step 2. Check the testvar iptvChannelRange to determine the number of channels
step 3. For each channel, join the multicast group on the LAN
step 4. Verify the IGMPv3 report is received in the WAN
step 5. Start sending multicast data on the WAN for the new group
step 6. Verify the LAN side starts to receive the multicast data
step 7. Wait for a small delay determined by testvar iptvChannelChangeDelay
step 8. Send new IGMPv3 report to leave current channel and join next channel
or exit if too many failures have occurred
NOTE: There are a few test variables that can control the number of channels
and speed of this test.
The testvar iptvChannelChangeDelay specifies a delay in milliseconds to wait
between each channel change.
The testvar iptvChannelRange specifies the total number of channel changes to
attempt.
The testvar iptvMaxFailures is used to stop the test after a specific number
of failures. When testing a large number of channels, it can be useful
to stop the test earily is many channels start failing.
References:
IETF RFC 2236 "Internet Group Management Protocol, Version 2"
https://tools.ietf.org/html/rfc2236
IETF RFC 3376 "Internet Group Management Protocol, Version 3"
https://tools.ietf.org/html/rfc3376
dyndns.tcl
Tests for routers with built in DynDNS clients
| Test |
Module |
Name |
Synopsis |
DynDNS client sends an update request when the WAN IP address changes |
dyndns.tcl |
cdrouter_dyndns_1 |
DynDNS client sends an update request when the WAN IP address changes |
Step 1: Terminate the WAN connection
Step 2: Reestablish the WAN connection with a different IP address
Step 3: Verify that the DynDNS client updated with the new IP address
Step 4: Terminate the WAN connection again
Step 5: Reestablish the WAN connection with the original IP address
Step 6: Verify that the DynDNS client updated again following the WAN address change
References:
Dynamic DNS Update API "Dyn.com Remote Access Update API -- Perform Update"
https://help.dyn.com/remote-access-api/perform-update/
| Test |
Module |
Name |
Synopsis |
DynDNS client does not update if the WAN reestablishes with the same IP address |
dyndns.tcl |
cdrouter_dyndns_2 |
DynDNS client does not update if the WAN reestablishes with the same IP address |
Step 1: Terminate the WAN connection
Step 2: Wait for the device to reestablish the WAN connection with the same IP address
Step 3: Observe DynDNS activity for a period of time
Step 4: Verify that no DynDNS updates were performed.
References:
Dynamic DNS Update API "Dyn.com Remote Access Update API -- Policies"
https://help.dyn.com/remote-access-api/policies/
| Test |
Module |
Name |
Synopsis |
DynDNS client sends correct parameters in update request |
dyndns.tcl |
cdrouter_dyndns_10 |
DynDNS client sends correct parameters in update request |
Step 1: Terminate the WAN connection
Step 2: Reestablish the WAN connection with a different IP address
Step 3: Verify that the DynDNS client updates with the new WAN IP address
Step 4: Compare the update parameters with their expected values specified in the config file
NOTE: The config file allows you to specify expected values for each of the DynDNS update parameters.
If the client being tested relies on the default value being used, leave the coresponding testvar
commented out.
References:
Dynamic DNS Update API "Dyn.com Remote Access Update API -- Perform Update"
https://help.dyn.com/remote-access-api/perform-update/
| Test |
Module |
Name |
Synopsis |
DynDNS client uses DNS to resolve the address of members.dyndns.org |
dyndns.tcl |
cdrouter_dyndns_20 |
DynDNS client uses DNS to resolve the address of members.dyndns.org |
Step 1: Disable the existing DynDNS server so it doesn't respond to any update requests
Step 2: Create a new DynDNS server on the WAN side on a free IP address
Step 3: Update the DNS entry of members.dyndns.org to resolve to the new DynDNS server
Step 4: Terminate the WAN connection
Step 5: Reestablish the WAN connection with a new IP address
Step 6: Verify the DynDNS client updates with the new DynDNS server
Step 7: Reset the WAN connection back to the original IP address; reset the original
DNS information for members.dyndns.org and reenable the original DynDNS server
References:
Dynamic DNS Update API "Dyn.com Remote Access Update API -- Policies"
https://help.dyn.com/remote-access-api/policies/
| Test |
Module |
Name |
Synopsis |
DynDNS client doesn't rely on DNS to determine if an update is necessary |
dyndns.tcl |
cdrouter_dyndns_50 |
DynDNS client doesn’t rely on DNS to determine if an update is necessary |
Step 1: Count the number of times the DynDNS client hostname has been queried in DNS
Step 2: Force a DynDNS update by changing the IP address on the WAN and reestablish a connection
Step 3: Observe DynDNS client activity for a period of time
Step 4: Count again the number of times the DynDNS client hostname has been queried in DNS
Step 5: Compare the count in Step 1 with the count in Step 2
Step 6: Reset the WAN connection to use the orignial IP address
NOTE: This test verifies that the DynDNS client is not using a DNS lookup to determine if an update
needs to be performed.
References:
Dynamic DNS Update API "Dyn.com Remote Access Update API -- Guidelines"
Clients should not perform DNS queries to determine whether
it is necessary to update. The danger is that the ISP’s DNS
server will be caching the old IP for a few minutes, leading
the client to conclude the update failed and causing a loop.
https://help.dyn.com/remote-access-api/guidelines/
| Test |
Module |
Name |
Synopsis |
DynDNS client reacts appropriately to error conditions |
dyndns.tcl |
cdrouter_dyndns_101 |
DynDNS client reacts appropriately to error conditions |
Step 1: Terminate the WAN connection
Step 2: Set the DynDNS server to return the specified error code
Step 3: Force a DynDNS update by changing the IP address on the WAN and reestablish a connection
Step 4: Observe DynDNS activity for a period of time
Step 5: Verify the DynDNS client stops updating after receiving the error message
NOTE: Following this test, the DynDNS client should not perform any updates until there has
been user confirmation that the problem is fixed. This will break any subsequent tests and
therefore must be run in isolation from other DynDNS tests.
Example:
testvar testDynDnsErrorCode yes
testvar dynDnsServerReturn <error code>
References:
Dynamic DNS Update API "Dyn.com Remote Access Update API -- Policies"
https://help.dyn.com/remote-access-api/policies/
Dynamic DNS Update API "Dyn.com Remote Access Update API -- Return Codes"
https://help.dyn.com/remote-access-api/return-codes/
sip-alg.tcl
SIP testing for SIP ALG or proxy
| Test |
Module |
Name |
Synopsis |
Verify NAT translation of SIP headers during REGISTER |
sip-alg.tcl |
cdrouter_sip_1 |
Verify NAT translation of SIP headers during REGISTER |
step 1. Send a REGISTER from LAN client to SIP proxy on WAN
step 2. Verify the private IPv4 address in the Contact header
is translated to the WAN side IPv4 address
step 3. Verify the private IPv4 address in the Via header
is translated to the WAN side IPv4 address; in the
case of a proxy, verify a new Via header is added
with the SIP ALGs public IPv4 address.
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation"
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00
| Test |
Module |
Name |
Synopsis |
Verify NAT translation of short format SIP headers during REGISTER |
sip-alg.tcl |
cdrouter_sip_2 |
Verify NAT translation of short format SIP headers during REGISTER |
step 1. Configure the SIP client and server to use short
header formats
step 2. Send a REGISTER from LAN client to SIP proxy on WAN
step 3. Verify the private IPv4 address in the Contact header
is translated to the WAN side IPv4 address
step 4. Verify the private IPv4 address in the Via header
is translated to the WAN side IPv4 address; in the
case of a proxy, verify a new Via header is added
with the SIP ALGs public IPv4 address.
References:
IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields
https://tools.ietf.org/html/rfc3261#section-20
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify NAT translation of SIP headers during outbound call |
sip-alg.tcl |
cdrouter_sip_10 |
Verify NAT translation of SIP headers during outbound call |
step 1. Register SIP client with SIP proxy on WAN
step 2. Initiate an outbound call to remote SIP destination
step 3. Verify the Contact and Via headers are updated
for the INVITE and BYE methods.
References:
IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields
https://tools.ietf.org/html/rfc3261#section-20
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify NAT translation of short format SIP headers during outbound call |
sip-alg.tcl |
cdrouter_sip_11 |
Verify NAT translation of short format SIP headers during outbound call |
step 1. Configure SIP client and server to use short format
for all SIP headers
step 2. Register SIP client with SIP proxy on WAN
step 3. Initiate an outbound call to remote SIP destination
step 4. Verify the Contact and Via headers are updated
for the INVITE and BYE methods.
References:
IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields
https://tools.ietf.org/html/rfc3261#section-20
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify NAT translation of SIP headers during inbound call |
sip-alg.tcl |
cdrouter_sip_20 |
Verify NAT translation of SIP headers during inbound call |
step 1. Register SIP client with SIP proxy on WAN
step 2. Initiate an inbound call to LAN side SIP destination
step 3. Verify the Contact and Via headers are updated
for the Resposes to INVITE and BYE methods
References:
IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields
https://tools.ietf.org/html/rfc3261#section-20
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify NAT translation of short format SIP headers during inbound call |
sip-alg.tcl |
cdrouter_sip_21 |
Verify NAT translation of short format SIP headers during inbound call |
step 1. Configure SIP client and server to use short format
for all SIP headers
step 2. Register SIP client with SIP proxy on WAN
step 3. Initiate an inbound call to LAN side SIP destination
step 4. Verify the Contact and Via headers are updated
for the Resposes to INVITE and BYE methods
References:
IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields
https://tools.ietf.org/html/rfc3261#section-20
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify NAT translation of SDP headers during outbound call |
sip-alg.tcl |
cdrouter_sip_30 |
Verify NAT translation of SDP headers during outbound call |
step 1. Register SIP client with SIP proxy on WAN
step 2. Initiate an outbound call to remote SIP destination
step 3. Verify the SDP Media and Connection fields are updated
with the public side IP address and port mapping
step 4. Initiate RTP stream in both directions
step 5. Verify RTP packets are flowing in both directions
step 6. End SIP call by sending 'BYE' from the LAN
step 7. Unregister SIP client
References:
IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields
https://tools.ietf.org/html/rfc3261#section-20
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify NAT translation of SDP headers during inbound call |
sip-alg.tcl |
cdrouter_sip_31 |
Verify NAT translation of SDP headers during inbound call |
step 1. Register SIP client with SIP proxy on WAN
step 2. Initiate an inbound call to remote SIP destination
step 3. For INVITE response from SIP client, verify the
SDP Media and Connection fields are updated
with the public side IP address and port mapping
step 4. Initiate RTP stream in both directions
step 5. Verify RTP packets are flowing in both directions
step 6. End SIP call by sending 'BYE' from the LAN
step 7. Unregister SIP client
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify SIP call with client using source port not equal to 5060 |
sip-alg.tcl |
cdrouter_sip_40 |
Verify SIP call with client using source port not equal to 5060 |
step 1. Configure SIP client to use a source port other than
5060 for SIP signaling
step 2. Register SIP client with SIP proxy on WAN
step 3. Initiate an outbound call to remote SIP destination
step 4. Initiate RTP stream in both directions
step 5. Verify RTP packets are flowing in both directions
step 6. End SIP call by sending 'BYE' from the LAN
step 7. Unregister SIP client
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify outbound SIP call with client 'Contact' header using different port |
sip-alg.tcl |
cdrouter_sip_41 |
Verify outbound SIP call with client ‘Contact’ header using different port |
step 1. Configure SIP client to use a source port in the Contact
header that is not the same as the SIP packet source port
step 2. Register SIP client with SIP proxy on WAN
step 3. Initiate an outbound call to remote SIP destination
step 4. Initiate RTP stream in both directions
step 5. Verify RTP packets are flowing in both directions
step 6. End SIP call by sending 'BYE' from the LAN
step 7. Unregister SIP client
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify inbound SIP call with client 'Contact' header using different port |
sip-alg.tcl |
cdrouter_sip_42 |
Verify inbound SIP call with client ‘Contact’ header using different port |
step 1. Configure SIP client to use a source port in the Contact
header that is not the same as the SIP packet source port
step 2. Register SIP client with SIP proxy on WAN
step 3. Initiate an inbound call to remote SIP destination
step 4. Initiate RTP stream in both directions
step 5. Verify RTP packets are flowing in both directions
step 6. End SIP call by sending 'BYE' from the LAN
step 7. Unregister SIP client
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify outbound SIP calls allow incoming RTP stream when caller uses mute |
sip-alg.tcl |
cdrouter_sip_43 |
Verify outbound SIP calls allow incoming RTP stream when caller uses mute |
step 1. Register SIP client with SIP proxy on WAN
step 2. Initiate an outbound call to remote SIP destination
step 3. Configure SIP client in "mute" mode so that no outbound
RTP traffic will be sent
step 4. When call is answered, send RTP stream from WAN side
SIP endpoint to the LAN side SIP client
step 5. Verify the SIP client on the LAN receives RTP stream
NOTE: This test verifies that the SIP ALG creates a NAT port mapping
for incoming RTP packets. If the SIP ALG relies on outgoing RTP packets
to set up the NAT port mapping for RTP, this test will fail. Some SIP
clients will not send any RTP packets when mute is enabled.
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation"
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00
| Test |
Module |
Name |
Synopsis |
Verify Via header port is used for response instead of UDP source port |
sip-alg.tcl |
cdrouter_sip_45 |
Verify Via header port is used for response instead of UDP source port |
step 1. Configure SIP client to use port 5060 in Via header
but send packets from a different UDP source port
step 2. Register SIP client with SIP proxy on WAN
step 3. Initiate an outbound call to remote SIP destination
step 4. Initiate RTP stream in both directions
step 5. Verify RTP packets are flowing in both directions
step 6. End SIP call by sending 'BYE' from the LAN
step 7. Unregister SIP client
NOTE: Some poorly implemented SIP clients use a Via header that does not
match the actual source packet of SIP request packets. The SIP ALG should
use the Via header information to formulate the SIP response and not the
source port of the UDP packet.
References:
IETF RFC 3261 "SIP: Session Initiation Protocol" Section 8.1.17: Via
https://tools.ietf.org/html/rfc3261#section-8.1.17
| Test |
Module |
Name |
Synopsis |
Verify NAT translation of SDP remains the same on retransmission of INVITE |
sip-alg.tcl |
cdrouter_sip_50 |
Verify NAT translation of SDP remains the same on retransmission of INVITE |
step 1. Register SIP client with SIP proxy on WAN
step 2. Configure SIP proxy not to respond to INVITES
step 3. Send INVITE with SDP descriptor from LAN to WAN SIP client
step 4. Verify SDP port and IPv4 address is translated to public IP
step 5. Resend INVITE with same Call ID and SDP information
step 6. Verify SDP translation remains the same
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation"
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00
| Test |
Module |
Name |
Synopsis |
Verify RTP port mapping is deleted when SIP client ends call (BYE) |
sip-alg.tcl |
cdrouter_sip_60 |
Verify RTP port mapping is deleted when SIP client ends call (BYE) |
step 1. Register SIP client with SIP proxy on WAN
step 2. Initiate an outbound call to remote SIP destination
step 3. Initiate RTP stream in both directions
step 4. Verify RTP packets are flowing in both directions
step 5. End SIP call by sending 'BYE' from the LAN
step 6. After call ends, wait sipCallTeardownDelay seconds
step 7. Send inbound RTP packets from WAN to LAN
using the same port numbers for the RTP connection
step 8. Verify the port mapping is now closed and the
RTP packets are not forwarded onto the LAN
step 9. Unregister SIP client
NOTE: The amount of time to wait after the call ends can be configured using
the testvar 'sipCallTeardownDelay'. Some ALGs explicitly delete a RTP port
mapping when the BYE exchange occurs. Others wait until no media packets
have been received.
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify RTP port mapping is deleted when SIP proxy ends call (BYE) |
sip-alg.tcl |
cdrouter_sip_61 |
Verify RTP port mapping is deleted when SIP proxy ends call (BYE) |
step 1. Register SIP client with SIP proxy on WAN
step 2. Initiate an outbound call to remote SIP destination
step 3. Initiate RTP stream in both directions
step 4. Verify RTP packets are flowing in both directions
step 5. End SIP call by sending 'BYE' from the WAN SIP Proxy
step 6. After call ends, send inbound RTP packets from WAN to LAN
using the same port numbers for the RTP connection
step 7. Verify the port mapping is now closed and the
RTP packets are not forwarded onto the LAN
step 8. Unregister SIP client
NOTE: The amount of time to wait after the call ends can be configured using
the testvar 'sipCallTeardownDelay'. Some ALGs explicitly delete a RTP port
mapping when the BYE exchange occurs. Others wait until no media packets
have been received.
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify RTP port mapping is deleted when SIP client cancels call (CANCEL) |
sip-alg.tcl |
cdrouter_sip_62 |
Verify RTP port mapping is deleted when SIP client cancels call (CANCEL) |
step 1. Register SIP client with SIP proxy on WAN
step 2. Initiate an outbound call to remote SIP destination
step 3. Configure the SIP proxy not to respond
step 4. End SIP call by sending 'CANCEL' from the LAN
step 5. After call ends, send inbound RTP packets from WAN to LAN
using the same port numbers for the RTP connection
step 6. Verify the port mapping is now closed and the
RTP packets are not forwarded onto the LAN
step 7. Unregister SIP client
NOTE: The amount of time to wait after the call ends can be configured using
the testvar 'sipCallTeardownDelay'. Some ALGs explicitly delete a RTP port
mapping when the BYE exchange occurs. Others wait until no media packets
have been received.
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify RTP port mapping is deleted or not established if call setup fails |
sip-alg.tcl |
cdrouter_sip_63 |
Verify RTP port mapping is deleted or not established if call setup fails |
step 1. Register SIP client with SIP proxy on WAN
step 2. Initiate an outbound call to remote SIP destination
step 3. Configure the SIP proxy to return 400 error
step 4. Verify the port mapping in INVITE is closed and the
RTP packets are not forwarded onto the LAN
step 5. Unregister SIP client
NOTE: The amount of time to wait after the call ends can be configured using
the testvar 'sipCallTeardownDelay'. Some ALGs explicitly delete a RTP port
mapping when the BYE exchange occurs. Others wait until no media packets
have been received.
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify SIP ALG with various SIP URI formats |
sip-alg.tcl |
cdrouter_sip_70 |
Verify SIP ALG with various SIP URI formats |
step 1. For each URI, register SIP client with SIP proxy on WAN
step 2. Initiate an outbound call to remote SIP destination
step 3. Verify outbound call succeeds and RTP traffic is flowing
step 4. End outbound SIP call from client side
step 5. Attempt inbound call to URI address
step 6. Verify inbound call succeeds and RTP traffic is flowing
step 7. End inbound SIP call from client side
step 8. Unregister SIP client
| Test |
Module |
Name |
Synopsis |
Verify outbound calls with multiple SIP clients using the same SIP and SDP ports |
sip-alg.tcl |
cdrouter_sip_71 |
Verify outbound calls with multiple SIP clients using the same SIP and SDP ports |
step 1. Configure an additional DHCP client on the LAN
step 2. Register 2 SIP clients with SIP proxy on WAN using
the same source port (5060) on the LAN side
step 3. Initiate an outbound call to remote SIP destination
from both SIP clients
step 4. For each call, initiate RTP streams in both directions
step 5. For each call, Verify RTP packets are flowing in both directions
step 6. End SIP call by sending 'BYE' from the LAN
step 7. Unregister both SIP clients
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify inbound calls with multiple SIP clients using the same SIP and SDP ports |
sip-alg.tcl |
cdrouter_sip_72 |
Verify inbound calls with multiple SIP clients using the same SIP and SDP ports |
step 1. Configure an additional DHCP client on the LAN
step 2. Register 2 SIP clients with SIP proxy on WAN using
the same source port (5060) on the LAN side
step 3. Initiate an inbound call to remote SIP destination
from both SIP clients
step 4. For each call, initiate RTP streams in both directions
step 5. For each call, Verify RTP packets are flowing in both directions
step 6. End SIP call by sending 'BYE' from the LAN
step 7. Unregister both SIP clients
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify outbound calls with multiple SIP clients using corner case port 65535 for SDP |
sip-alg.tcl |
cdrouter_sip_73 |
Verify outbound calls with multiple SIP clients using corner case port 65535 for SDP |
step 1. Configure an additional DHCP client on the LAN
step 2. Register 2 SIP clients with SIP proxy on WAN using
the same source port (5060) on the LAN side
step 3. Initiate an outbound call to remote SIP destination
from both SIP clients with both clients using SDP
port 65534-65535
step 4. For each call, initiate RTP streams in both directions
step 5. For each call, Verify RTP packets are flowing in both directions
step 6. End SIP call by sending 'BYE' from the LAN
step 7. Unregister both SIP clients
NOTE: This test verifies that the SIP-ALG is able to support the maximum
port number that is allowed.
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify outbound SIP calls when server uses early media SDP setup |
sip-alg.tcl |
cdrouter_sip_80 |
Verify outbound SIP calls when server uses early media SDP setup |
step 1. Register SIP client with SIP proxy on WAN
step 2. Initiate an outbound call to remote SIP destination
step 3. Configure SIP server to return 183 Session Progress that
includes SDP media setup
step 4. Server side will start sending RTP stream
step 5. Verify the SIP client on the LAN receives RTP stream
NOTE: This test verifies that the SIP ALG creates a NAT port mapping
for incoming RTP packets when 183 Session Progress with SDP is used by
the SIP server. If the SIP ALG relies on outgoing RTP packets to set
up the NAT port mapping for RTP, this test will fail.
References:
IETF RFC 3261 "SIP: Session Initiation Protocol" Section 21.1.5: 183 Session Progress
https://tools.ietf.org/html/rfc3261#section-21.1.5
| Test |
Module |
Name |
Synopsis |
Verify maximum number of simultaneous outbound SIP calls |
sip-alg.tcl |
cdrouter_sip_100 |
Verify maximum number of simultaneous outbound SIP calls |
step 1. Register SIP client with SIP proxy on WAN
step 2. Initiate an outbound call to unique remote SIP destination
step 3. Continue to initiate calls up to sipMaxOutboundCalls
step 4. For each call, verify RTP traffic is flowing in both directions
step 5. End each call by sending 'BYE' from the LAN
step 6. Unregister SIP client
NOTES:
The number of outbound SIP calls attempted is controlled by the testvar
'sipMaxOutboundCalls'. It defaults to 10.
For this testing scenario, the pace of the RTP stream is slowed down to
allow fewer RTP packets per stream. The actual RTP send interval can be
configured using the testvar 'rtpSendInterval'. This is the interval between
each RTP packet in milliseconds. The default value is 5000 milliseconds.
An additional pacing time can be configured between each SIP call using the
testvar 'sipCallPacing'. This value is in milliseconds.
Once all outbound SIP calls have been attempted, the test will let the calls
run for 30 seconds by default. This duration can be changed using the
testvar 'sipScaleRunTime'. The duration must be long enough to allow each
RTP stream to send and receive at least 2 packets. This value is in seconds.
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify maximum number of simultaneous inbound SIP calls |
sip-alg.tcl |
cdrouter_sip_101 |
Verify maximum number of simultaneous inbound SIP calls |
step 1. Register SIP client with SIP proxy on WAN
step 2. Initiate an inbound call from unique remote SIP destination
step 3. Continue to initiate calls up to sipMaxInboundCalls
step 4. For each call, verify RTP traffic is flowing in both directions
step 5. End each call by sending 'BYE' from the WAN
step 6. Unregister SIP client
NOTES:
The number of inbound SIP calls attempted is controlled by the testvar
'sipMaxInboundCalls'. It defaults to 10.
For this testing scenario, the pace of the RTP stream is slowed down to
allow fewer RTP packets per stream. The actual RTP send interval can be
configured using the testvar 'rtpSendInterval'. This is the interval between
each RTP packet in milliseconds. The default value is 5000 milliseconds.
An additional pacing time can be configured between each SIP call using the
testvar 'sipCallPacing'. This value is in milliseconds.
Once all inbound SIP calls have been attempted, the test will let the calls
run for 30 seconds by default. The call duration can be changed using the
testvar 'sipScaleRunTime'. The duration must be long enough to allow each
RTP stream to send and receive at least 2 packets. This value is in seconds.
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify outbound SIP calls with multiple DHCP LAN clients |
sip-alg.tcl |
cdrouter_sip_200 |
Verify outbound SIP calls with multiple DHCP LAN clients |
step 1. Create a DHCP client for each SIP call
step 2. Register each SIP client with SIP proxy on WAN
step 3. Initiate an outbound call to remote SIP destination
step 4. Continue to initiate calls up to sipMaxOutboundCalls
step 5. For each call, verify RTP traffic is flowing in both directions
step 6. End each call by sending 'BYE' from the LAN
step 7. Unregister SIP client
step 8. Release all new DHCP client leases
NOTES:
The number of outbound SIP calls attempted is controlled by the testvar
'sipMaxOutboundCalls'. It defaults to 10.
By default, the SIP server and client use port 5060. The SIP server port may
be configured using the testvar sipScaleServerPort. The sipScaleClientPort
testvar may be used to configure a specific SIP client source port for the
clients. The value of unique may also be specified to dynamically allocate
the SIP client port.
Example:
testvar sipScaleServerPort 10001
testvar sipScaleClientPort unique
For this testing scenario, the pace of the RTP stream is slowed down to
allow fewer RTP packets per stream. The actual RTP send interval can be
configured using the testvar 'rtpSendInterval'. This is the interval between
each RTP packet in milliseconds. The default value is 5000 milliseconds. If
this is increased to a larger value, changing the value of 'sipScaleRunTime'
should also be increased. This controls the duration must be long enough to
allow each RTP stream to send and receive at least 2 packets. This value is
in seconds.
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify outbound SIP calls with multiple DHCP LAN clients without registering a port |
sip-alg.tcl |
cdrouter_sip_201 |
Verify outbound SIP calls with multiple DHCP LAN clients without registering a port |
step 1. Create a DHCP client for each SIP call
step 2. Register each SIP client with SIP proxy on WAN without specifying any port numbers
step 3. Initiate an outbound call to remote SIP destination
step 4. Continue to initiate calls up to sipMaxOutboundCalls
step 5. For each call, verify RTP traffic is flowing in both directions
step 6. End each call by sending 'BYE' from the LAN
step 7. Unregister SIP client
step 8. Release all new DHCP client leases
NOTES:
The number of outbound SIP calls attempted is controlled by the testvar
'sipMaxOutboundCalls'. It defaults to 10.
This test will start the SIP server and SIP clients on the default port of
5060.
For this testing scenario, the pace of the RTP stream is slowed down to
allow fewer RTP packets per stream. The actual RTP send interval can be
configured using the testvar 'rtpSendInterval'. This is the interval between
each RTP packet in milliseconds. The default value is 5000 milliseconds. If
this is increased to a larger value, changing the value of 'sipScaleRunTime'
should also be increased. This controls the duration must be long enough to
allow each RTP stream to send and receive at least 2 packets. This value is
in seconds.
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
sip-alg-tcp.tcl
SIP over TCP testing for SIP ALG or proxy
| Test |
Module |
Name |
Synopsis |
Verify NAT translation of SIP headers during REGISTER (TCP) |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_1 |
Verify NAT translation of SIP headers during REGISTER (TCP) |
step 1. Send a REGISTER from LAN client to SIP proxy on WAN
step 2. Verify the private IPv4 address in the Contact header
is translated to the WAN side IPv4 address
step 3. Verify the private IPv4 address in the Via header
is translated to the WAN side IPv4 address; in the
case of a proxy, verify a new Via header is added
with the SIP ALGs public IPv4 address.
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation"
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00
| Test |
Module |
Name |
Synopsis |
Verify NAT translation of short format SIP headers during REGISTER (TCP) |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_2 |
Verify NAT translation of short format SIP headers during REGISTER (TCP) |
step 1. Configure the SIP client and server to use short
header formats
step 2. Send a REGISTER from LAN client to SIP proxy on WAN
step 3. Verify the private IPv4 address in the Contact header
is translated to the WAN side IPv4 address
step 4. Verify the private IPv4 address in the Via header
is translated to the WAN side IPv4 address; in the
case of a proxy, verify a new Via header is added
with the SIP ALGs public IPv4 address.
References:
IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields
https://tools.ietf.org/html/rfc3261#section-20
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify NAT translation of SIP headers during outbound call (TCP) |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_10 |
Verify NAT translation of SIP headers during outbound call (TCP) |
step 1. Register SIP client with SIP proxy on WAN
step 2. Initiate an outbound call to remote SIP destination
step 3. Verify the Contact and Via headers are updated
for the INVITE and BYE methods.
References:
IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields
https://tools.ietf.org/html/rfc3261#section-20
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify NAT translation of short format SIP headers during outbound call (TCP) |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_11 |
Verify NAT translation of short format SIP headers during outbound call (TCP) |
step 1. Configure SIP client and server to use short format
for all SIP headers
step 2. Register SIP client with SIP proxy on WAN
step 3. Initiate an outbound call to remote SIP destination
step 4. Verify the Contact and Via headers are updated
for the INVITE and BYE methods.
References:
IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields
https://tools.ietf.org/html/rfc3261#section-20
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify NAT translation of SIP headers during inbound call (TCP) |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_20 |
Verify NAT translation of SIP headers during inbound call (TCP) |
step 1. Register SIP client with SIP proxy on WAN
step 2. Initiate an inbound call to LAN side SIP destination
step 3. Verify the Contact and Via headers are updated
for the Resposes to INVITE and BYE methods
References:
IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields
https://tools.ietf.org/html/rfc3261#section-20
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify NAT translation of short format SIP headers during inbound call (TCP) |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_21 |
Verify NAT translation of short format SIP headers during inbound call (TCP) |
step 1. Configure SIP client and server to use short format
for all SIP headers
step 2. Register SIP client with SIP proxy on WAN
step 3. Initiate an inbound call to LAN side SIP destination
step 4. Verify the Contact and Via headers are updated
for the Resposes to INVITE and BYE methods
References:
IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields
https://tools.ietf.org/html/rfc3261#section-20
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify NAT translation of SDP headers during outbound call (TCP) |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_30 |
Verify NAT translation of SDP headers during outbound call (TCP) |
step 1. Register SIP client with SIP proxy on WAN
step 2. Initiate an outbound call to remote SIP destination
step 3. Verify the SDP Media and Connection fields are updated
with the public side IP address and port mapping
step 4. Initiate RTP stream in both directions
step 5. Verify RTP packets are flowing in both directions
step 6. End SIP call by sending 'BYE' from the LAN
step 7. Unregister SIP client
References:
IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields
https://tools.ietf.org/html/rfc3261#section-20
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify NAT translation of SDP headers during inbound call (TCP) |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_31 |
Verify NAT translation of SDP headers during inbound call (TCP) |
step 1. Register SIP client with SIP proxy on WAN
step 2. Initiate an inbound call to remote SIP destination
step 3. For INVITE response from SIP client, verify the
SDP Media and Connection fields are updated
with the public side IP address and port mapping
step 4. Initiate RTP stream in both directions
step 5. Verify RTP packets are flowing in both directions
step 6. End SIP call by sending 'BYE' from the LAN
step 7. Unregister SIP client
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify SIP call with client using source port not equal to 5060 (TCP) |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_40 |
Verify SIP call with client using source port not equal to 5060 (TCP) |
step 1. Configure SIP client to use a source port other than
5060 for SIP signaling
step 2. Register SIP client with SIP proxy on WAN
step 3. Initiate an outbound call to remote SIP destination
step 4. Initiate RTP stream in both directions
step 5. Verify RTP packets are flowing in both directions
step 6. End SIP call by sending 'BYE' from the LAN
step 7. Unregister SIP client
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify outbound SIP call with client 'Contact' header using different port (TCP) |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_41 |
Verify outbound SIP call with client ‘Contact’ header using different port (TCP) |
step 1. Configure SIP client to use a source port in the Contact
header that is not the same as the source port as the
SIP packet source port
step 2. Register SIP client with SIP proxy on WAN
step 3. Initiate an outbound call to remote SIP destination
step 4. Initiate RTP stream in both directions
step 5. Verify RTP packets are flowing in both directions
step 6. End SIP call by sending 'BYE' from the LAN
step 7. Unregister SIP client
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify inbound SIP call with client 'Contact' header using different port (TCP) |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_42 |
Verify inbound SIP call with client ‘Contact’ header using different port (TCP) |
step 1. Configure SIP client to use a source port in the Contact
header that is not the same as the SIP packet source port
step 2. Register SIP client with SIP proxy on WAN
step 3. Initiate an inbound call to remote SIP destination
step 4. Initiate RTP stream in both directions
step 5. Verify RTP packets are flowing in both directions
step 6. End SIP call by sending 'BYE' from the LAN
step 7. Unregister SIP client
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify outbound SIP calls allow incoming RTP stream when caller uses mute (TCP) |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_43 |
Verify outbound SIP calls allow incoming RTP stream when caller uses mute (TCP) |
step 1. Register SIP client with SIP proxy on WAN
step 2. Initiate an outbound call to remote SIP destination
step 3. Configure SIP client in "mute" mode so that no outbound
RTP traffic will be sent
step 4. When call is answered, send RTP stream from WAN side
SIP endpoint to the LAN side SIP client
step 5. Verify the SIP client on the LAN receives RTP stream
NOTE: This test verifies that the SIP ALG creates a NAT port mapping for
incoming RTP packets. If the SIP ALG relies on outgoing RTP packets to set
up the NAT port mapping for RTP, this test will fail. Some SIP clients will
not send any RTP packets when mute is enabled.
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation"
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00
| Test |
Module |
Name |
Synopsis |
Verify Via header port is used for response instead of TCP source port (TCP) |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_45 |
Verify Via header port is used for response instead of TCP source port (TCP) |
step 1. Configure SIP client to use port 5060 in Via header
but send packets from a different TCP source port
step 2. Register SIP client with SIP proxy on WAN
step 3. Initiate an outbound call to remote SIP destination
step 4. Initiate RTP stream in both directions
step 5. Verify RTP packets are flowing in both directions
step 6. End SIP call by sending 'BYE' from the LAN
step 7. Unregister SIP client
NOTE: Some poorly implemented SIP clients use a Via header that does not
match the actual source packet of SIP request packets. The SIP ALG should
use the Via header information to formulate the SIP response and not the
source port of the TCP packet.
References:
IETF RFC 3261 "SIP: Session Initiation Protocol" Section 8.1.1.7: Via
https://tools.ietf.org/html/rfc3261#section-8.1.1.7
| Test |
Module |
Name |
Synopsis |
Verify NAT translation of SDP remains the same on retransmission of INVITE (TCP) |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_50 |
Verify NAT translation of SDP remains the same on retransmission of INVITE (TCP) |
step 1. Register SIP client with SIP proxy on WAN
step 2. Configure SIP proxy not to respond to INVITES
step 3. Send INVITE with SDP descriptor from LAN to WAN SIP client
step 4. Verify SDP port and IPv4 address is translated to public IP
step 5. Resend INVITE with same Call ID and SDP information
step 6. Verify SDP translation remains the same
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation"
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00
| Test |
Module |
Name |
Synopsis |
Verify RTP port mapping is deleted when SIP client ends call (BYE) (TCP) |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_60 |
Verify RTP port mapping is deleted when SIP client ends call (BYE) (TCP) |
step 1. Register SIP client with SIP proxy on WAN
step 2. Initiate an outbound call to remote SIP destination
step 3. Initiate RTP stream in both directions
step 4. Verify RTP packets are flowing in both directions
step 5. End SIP call by sending 'BYE' from the LAN
step 6. After call ends, wait sipCallTeardownDelay seconds
step 7. Send inbound RTP packets from WAN to LAN
using the same port numbers for the RTP connection
step 8. Verify the port mapping is now closed and the
RTP packets are not forwarded onto the LAN
step 9. Unregister SIP client
NOTE: The amount of time to wait after the call ends can be configured using
the testvar 'sipCallTeardownDelay'. Some ALGs explicitly delete a RTP port
mapping when the BYE exchange occurs. Others wait until no media packets
have been received.
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify RTP port mapping is deleted when SIP proxy ends call (BYE) (TCP) |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_61 |
Verify RTP port mapping is deleted when SIP proxy ends call (BYE) (TCP) |
step 1. Register SIP client with SIP proxy on WAN
step 2. Initiate an outbound call to remote SIP destination
step 3. Initiate RTP stream in both directions
step 4. Verify RTP packets are flowing in both directions
step 5. End SIP call by sending 'BYE' from the WAN SIP Proxy
step 6. After call ends, send inbound RTP packets from WAN to LAN
using the same port numbers for the RTP connection
step 7. Verify the port mapping is now closed and the
RTP packets are not forwarded onto the LAN
step 8. Unregister SIP client
NOTE: The amount of time to wait after the call ends can be configured using
the testvar 'sipCallTeardownDelay'. Some ALGs explicitly delete a RTP port
mapping when the BYE exchange occurs. Others wait until no media packets
have been received.
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify RTP port mapping is deleted when SIP client cancels call (CANCEL) (TCP) |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_62 |
Verify RTP port mapping is deleted when SIP client cancels call (CANCEL) (TCP) |
step 1. Register SIP client with SIP proxy on WAN
step 2. Initiate an outbound call to remote SIP destination
step 3. Configure the SIP proxy not to respond
step 4. End SIP call by sending 'CANCEL' from the LAN
step 5. After call ends, send inbound RTP packets from WAN to LAN
using the same port numbers for the RTP connection
step 6. Verify the port mapping is now closed and the
RTP packets are not forwarded onto the LAN
step 7. Unregister SIP client
NOTE: The amount of time to wait after the call ends can be configured using
the testvar 'sipCallTeardownDelay'. Some ALGs explicitly delete a RTP port
mapping when the BYE exchange occurs. Others wait until no media packets
have been received.
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify RTP port mapping is deleted or not established if call setup fails (TCP) |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_63 |
Verify RTP port mapping is deleted or not established if call setup fails (TCP) |
step 1. Register SIP client with SIP proxy on WAN
step 2. Initiate an outbound call to remote SIP destination
step 3. Configure the SIP proxy to return 400 error
step 4. Verify the port mapping in INVITE is closed and the
RTP packets are not forwarded onto the LAN
step 5. Unregister SIP client
NOTE: The amount of time to wait after the call ends can be configured using
the testvar 'sipCallTeardownDelay'. Some ALGs explicitly delete a RTP port
mapping when the BYE exchange occurs. Others wait until no media packets
have been received.
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify SIP ALG with various SIP URI formats (TCP) |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_70 |
Verify SIP ALG with various SIP URI formats (TCP) |
step 1. For each URI, register SIP client with SIP proxy on WAN
step 2. Initiate an outbound call to remote SIP destination
step 3. Verify outbound call succeeds and RTP traffic is flowing
step 4. End outbound SIP call from client side
step 5. Attempt inbound call to URI address
step 6. Verify inbound call succeeds and RTP traffic is flowing
step 7. End inbound SIP call from client side
step 8. Unregister SIP client
| Test |
Module |
Name |
Synopsis |
Verify outbound calls with multiple SIP clients using the same SIP and SDP ports (TCP) |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_71 |
Verify outbound calls with multiple SIP clients using the same SIP and SDP ports (TCP) |
step 1. Configure an additional DHCP client on the LAN
step 2. Register 2 SIP clients with SIP proxy on WAN using
the same source port on the LAN side
step 3. Initiate an outbound call to remote SIP destination
from both SIP clients
step 4. For each call, initiate RTP streams in both directions
step 5. For each call, Verify RTP packets are flowing in both directions
step 6. End SIP call by sending 'BYE' from the LAN
step 7. Unregister both SIP clients
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify inbound calls with multiple SIP clients using the same SIP and SDP ports (TCP) |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_72 |
Verify inbound calls with multiple SIP clients using the same SIP and SDP ports (TCP) |
step 1. Configure an additional DHCP client on the LAN
step 2. Register 2 SIP clients with SIP proxy on WAN using
the same source port (5060) on the LAN side
step 3. Initiate an inbound call to remote SIP destination
from both SIP clients
step 4. For each call, initiate RTP streams in both directions
step 5. For each call, Verify RTP packets are flowing in both directions
step 6. End SIP call by sending 'BYE' from the LAN
step 7. Unregister both SIP clients
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify outbound calls with multiple SIP clients using corner case port 65535 for SDP (TCP) |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_73 |
Verify outbound calls with multiple SIP clients using corner case port 65535 for SDP (TCP) |
step 1. Configure an additional DHCP client on the LAN
step 2. Register 2 SIP clients with SIP proxy on WAN using
the same source port on the LAN side
step 3. Initiate an outbound call to remote SIP destination
from both SIP clients with both clients using SDP
port 65534-65535
step 4. For each call, initiate RTP streams in both directions
step 5. For each call, Verify RTP packets are flowing in both directions
step 6. End SIP call by sending 'BYE' from the LAN
step 7. Unregister both SIP clients
NOTE: This test verifies that the SIP-ALG is able to support the maximum
port number that is allowed.
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify outbound SIP calls when server uses early media SDP setup (TCP) |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_80 |
Verify outbound SIP calls when server uses early media SDP setup (TCP) |
step 1. Register SIP client with SIP proxy on WAN
step 2. Initiate an outbound call to remote SIP destination
step 3. Configure SIP server to return 183 Session Progress that
includes SDP media setup
step 4. Server side will start sending RTP stream
step 5. Verify the SIP client on the LAN receives RTP stream
NOTE: This test verifies that the SIP ALG creates a NAT port mapping for
incoming RTP packets when 183 Session Progress with SDP is used by the SIP
server. If the SIP ALG relies on outgoing RTP packets to set up the NAT port
mapping for RTP, this test will fail.
References:
IETF RFC 3261 "SIP: Session Initiation Protocol" Section 21.1.5: 183 Session Progress
https://tools.ietf.org/html/rfc3261#section-21.1.5
| Test |
Module |
Name |
Synopsis |
Verify maximum number of simultaneous outbound SIP calls (TCP) |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_100 |
Verify maximum number of simultaneous outbound SIP calls (TCP) |
step 1. Register SIP client with SIP proxy on WAN
step 2. Initiate an outbound call to unique remote SIP destination
step 3. Continue to initiate calls up to sipMaxOutboundCalls
step 4. For each call, verify RTP traffic is flowing in both directions
step 5. End each call by sending 'BYE' from the LAN
step 6. Unregister SIP client
NOTES:
The number of outbound SIP calls attempted is controlled by the testvar
'sipMaxOutboundCalls'. It defaults to 10.
For this testing scenario, the pace of the RTP stream is slowed down to
allow fewer RTP packets per stream. The actual RTP send interval can be
configured using the testvar 'rtpSendInterval'. This is the interval between
each RTP packet in milliseconds. The default value is 5000 milliseconds.
An additional pacing time can be configured between each SIP call using the
testvar 'sipCallPacing'. This value is in milliseconds.
Once all outbound SIP calls have been attempted, the test will let the calls
run for 30 seconds by default. This duration can be changed using the
testvar 'sipScaleRunTime'. The duration must be long enough to allow each
RTP stream to send and receive at least 2 packets. This value is in seconds.
References:
IETF RFC 3261 "SIP: Session Initiation Protocol" Section 21.1.5: 183 Session Progress
https://tools.ietf.org/html/rfc3261#section-21.1.5
| Test |
Module |
Name |
Synopsis |
Verify maximum number of simultaneous inbound SIP calls (TCP) |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_101 |
Verify maximum number of simultaneous inbound SIP calls (TCP) |
step 1. Register SIP client with SIP proxy on WAN
step 2. Initiate an inbound call from unique remote SIP destination
step 3. Continue to initiate calls up to sipMaxInboundCalls
step 4. For each call, verify RTP traffic is flowing in both directions
step 5. End each call by sending 'BYE' from the WAN
step 6. Unregister SIP client
NOTES:
The number of inbound SIP calls attempted is controlled by the testvar
'sipMaxInboundCalls'. It defaults to 10.
For this testing scenario, the pace of the RTP stream can be slowed down to
allow fewer RTP packets per stream. The actual RTP send interval can be
configured using the testvar 'rtpSendInterval'. This is the interval between
each RTP packet in milliseconds. The default value is 5000 milliseconds.
An additional pacing time can be configured between each SIP call using the
testvar 'sipCallPacing'. This value is in milliseconds.
Once all inbound SIP calls have been attempted, the test will let the calls
run for 30 seconds by default. This duration can be changed using the
testvar 'sipScaleRunTime'. The duration must be long enought to allow each
RTP stream to send and receive at least 2 packets. This value is in seconds.
References:
IETF RFC 3261 "SIP: Session Initiation Protocol" Section 21.1.5: 183 Session Progress
https://tools.ietf.org/html/rfc3261#section-21.1.5
| Test |
Module |
Name |
Synopsis |
Verify outbound SIP calls with multiple DHCP LAN clients (TCP) |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_200 |
Verify outbound SIP calls with multiple DHCP LAN clients (TCP) |
step 1. Create a DHCP client for each SIP call
step 2. Register each SIP client with SIP proxy on WAN
step 3. Initiate an outbound call to remote SIP destination
step 4. Continue to initiate calls up to sipMaxOutboundCalls
step 5. For each call, verify RTP traffic is flowing in both directions
step 6. End each call by sending 'BYE' from the LAN
step 7. Unregister SIP client
step 8. Release all new DHCP client leases
NOTES:
The number of outbound SIP calls attempted is controlled by the testvar
'sipMaxOutboundCalls'. It defaults to 10.
By default, the SIP server and client use port 5060. The SIP server port may
be configured using the testvar sipScaleServerPort. The sipScaleClientPort
testvar may be used to configure a specific SIP client source port for the
clients. The value of unique may also be specified to dynamically allocate
the SIP client port.
Example:
testvar sipScaleServerPort 10001
testvar sipScaleClientPort unique
For this testing scenario, the pace of the RTP stream is slowed down to
allow fewer RTP packets per stream. The actual RTP send interval can be
configured using the testvar 'rtpSendInterval'. This is the interval between
each RTP packet in milliseconds. The default value is 5000 milliseconds. The
call duration can be changed using the testvar 'sipScaleRunTime'. The
duration must be long enough to allow each RTP stream to send and receive at
least 2 packets. This value is in seconds.
References:
IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1
| Test |
Module |
Name |
Synopsis |
Verify outbound SIP calls with multiple DHCP LAN clients (TCP) without registering a port |
sip-alg-tcp.tcl |
cdrouter_sip_tcp_201 |
Verify outbound SIP calls with multiple DHCP LAN clients (TCP) without registering a port |
step 1. Create a DHCP client for each SIP call
step 2. Register each SIP client with SIP proxy on WAN without specifying any port numbers
step 3. Initiate an outbound call to remote SIP destination
step 4. Continue to initiate calls up to sipMaxOutboundCalls
step 5. For each call, verify RTP traffic is flowing in both directions
step 6. End each call by sending 'BYE' from the LAN
step 7. Unregister SIP client
step 8. Release all new DHCP client leases
Reference:
A SIP Application Level Gateway for Network Address Translation
IETF Draft draft-biggs-sip-nat-00.txt
Section 3.1 Outgoing SIP Message Mangling
NOTES:
The number of outbound SIP calls attempted is controlled by the
testvar 'sipMaxOutboundCalls'. It defaults to 10.
This test will start the SIP server and SIP clients on the default
port of 5060.
For this testing scenario, the pace of the RTP stream is slowed down
to allow fewer RTP packets per stream. The actual RTP send interval
can be configured using the testvar 'rtpSendInterval'. This is the
interval between each RTP packet in milliseconds. The default value is
5000 milliseconds. The call duration can be changed using the testvar
'sipScaleRunTime'. The duration must be long enough to allow each
RTP stream to send and receive at least 2 packets. This value is in seconds.
dns.tcl
DNS proxy and DNS failover related tests
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy does not cache DNS entry when DNS TTL is 0 |
dns.tcl |
dns_10 |
Verify DNS proxy does not cache DNS entry when DNS TTL is 0 |
step 1. Initiate a DNS lookup for a new unique hostname from the LAN
client to the configured DNS server
step 2. Return DNS response with TTL set to 0 from WAN DNS server
step 3. Change the IP address on the DNS server for the new hostname
step 4. Initiate a new DNS lookup for the same hostname
step 5. Verify a new DNS request is sent to the primary or backup
DNS servers
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format
https://tools.ietf.org/html/rfc1035#section-3.2.1
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy returns TTL of 0 when returned DNS TTL is 0 |
dns.tcl |
dns_11 |
Verify DNS proxy returns TTL of 0 when returned DNS TTL is 0 |
step 1. Initiate a DNS lookup for a new unique hostname from the LAN
client to the configured DNS server
step 2. Return DNS response with TTL set to 0 from WAN DNS server
step 3. Verify the returned TTL from the DNS proxy is 0
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format
https://tools.ietf.org/html/rfc1035#section-3.2.1
| Test |
Module |
Name |
Synopsis |
Verify AAAA IPv6 DNS queries to router are forwarded to real DNS server |
dns.tcl |
dns_40 |
Verify AAAA IPv6 DNS queries to router are forwarded to real DNS server |
step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return response back to LAN
step 5. Verify the response is received by LAN client
NOTE: The router must support some type of DNS relay or proxy to
pass this test case. The DNS relay or proxy must understand IPv6 DNS
type AAAA lookups.
References:
IETF RFC 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses"
https://tools.ietf.org/html/rfc4074
| Test |
Module |
Name |
Synopsis |
Verify AAAA IPv6 DNS queries can return no address for IPv6 to IPv4 failover |
dns.tcl |
dns_41 |
Verify AAAA IPv6 DNS queries can return no address for IPv6 to IPv4 failover |
step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send an empty return response back to LAN
step 5. Verify the response is received by LAN client
NOTE: The router must support some type of DNS relay or proxy to
pass this test case. The DNS relay or proxy must understand IPv6
DNS type AAAA lookups.
References:
IETF RFC 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses"
https://tools.ietf.org/html/rfc4074
| Test |
Module |
Name |
Synopsis |
Verify DNS failover when non-zero error codes are received in non-authoritative DNS response |
dns.tcl |
dns_45 |
Verify DNS failover when non-zero error codes are received in non-authoritative DNS response |
step 1. Verify DNS error codes from 1 - 15.
step 2. For each error code, send 3 DNS queries for a unique
hostname to the DUT's LAN IP address.
step 3. Verify a valid DNS response was received for all 3 DNS
queries.
step 4. Verify that all 3 DNS queries were received on the same
WAN DNS server address, known as the current primary DNS
server address.
step 5. Configure DNS queries sent to the current primary DNS
server address to return the error code, and all other DNS
server addresses to return the normal response.
step 6. All error responses from the current primary DNS server
address will have the authoritative bit not set.
step 7. Send 3 DNS queries for another unique hostname to the
DUT's LAN IP address.
step 8. Verify a valid DNS response is received if the error code
is expected to trigger DNS failover.
step 9. Verify that a DNS query was received on the current
primary DNS server address.
NOTE: Most DNS clients that support multiple DNS servers (primary and
backup) use some type of failover for certain DNS error codes. The behavior
for each error code is implementation dependent. The list of error codes
that will cause DNS failover can be configured using the testvar
'dnsFailoverNonAuth'. If no DNS error codes will cause failover, the testvar
should be configured with the keyword 'none'.
Example:
testvar dnsFailoverNonAuth "2 4 5"
Example with no failover support:
testvar dnsFailoverNonAuth none
NOTE: Unix OSes based on bind will normally failover if DNS error
codes 2, 4, or 5 are received. Windows based OSes will normally
failover on all DNS error codes except 3 (No Such Name).
NOTE: In most configurations the DUT will learn the IPv4 and/or IPv6
addresses of several DNS servers on the WAN. While CDRouter will Initiate
all DNS queries on the LAN over IPv4 in this test, the DUT may use any of
the DNS servers in its list (IPv4 of IPv6) for final resolution.
| Test |
Module |
Name |
Synopsis |
Verify DNS failover when non-zero error codes are received in authoritative DNS response |
dns.tcl |
dns_46 |
Verify DNS failover when non-zero error codes are received in authoritative DNS response |
step 1. Verify DNS error codes from 1 - 15.
step 2. For each error code, send 3 DNS queries for a unique
hostname to the DUT's LAN IP address.
step 3. Verify a valid DNS response was received for all 3 DNS
queries.
step 4. Verify that all 3 DNS queries were received on the same
WAN DNS server address, known as the current primary DNS
server address.
step 5. Configure DNS queries sent to the current primary DNS
server address to return the error code, and all other DNS
server addresses to return the normal response.
step 6. All error responses from the current primary DNS server
address will have the authoritative bit set.
step 7. Send 3 DNS queries for another unique hostname to the
DUT's LAN IP address.
step 8. Verify a valid DNS response is received if the error code
is expected to trigger DNS failover.
step 9. Verify that a DNS query was received on the current
primary DNS server address.
NOTE: Most DNS clients that support multiple DNS servers (primary and
backup) use some type of failover for certain DNS error codes. The behavior
for each error code is implementation dependent. The list of error codes
that will cause DNS failover can be configured using the testvar
'dnsFailoverAuth'. If no DNS error codes will cause failover, the testvar
should be configured with the keyword 'none'.
Example:
testvar dnsFailoverAuth "2 4 5"
Example with no failover support:
testvar dnsFailoverAuth none
NOTE: Unix OSes based on bind will normally failover if DNS error
codes 2, 4, or 5 are received. Windows based OSes will normally
failover on all DNS error codes except 3 (No Such Name).
NOTE: In most configurations the DUT will learn the IPv4 and/or IPv6
addresses of several DNS servers on the WAN. While CDRouter will Initiate
all DNS queries on the LAN over IPv4 in this test, the DUT may use any of
the DNS servers in its list (IPv4 of IPv6) for final resolution.
| Test |
Module |
Name |
Synopsis |
Verify Reverse PTR DNS queries to router are forwarded to real DNS server |
dns.tcl |
dns_50 |
Verify Reverse PTR DNS queries to router are forwarded to real DNS server |
step 1. Initiate a reverse DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return response back to LAN
step 5. Verify the response is received by LAN client
NOTE: The router must support some type of DNS relay or proxy to
pass this test case.
| Test |
Module |
Name |
Synopsis |
Verify Reverse AAAA IPv6 DNS queries to router are forwarded to real DNS server |
dns.tcl |
dns_51 |
Verify Reverse AAAA IPv6 DNS queries to router are forwarded to real DNS server |
step 1. Initiate a reverse AAAA IPv6 DNS query from the LAN client
to the configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return response back to LAN
step 5. Verify the response is received by LAN client
NOTE: The router must support some type of DNS relay or proxy to
pass this test case.
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy fails over when new primary DNS server is learned |
dns.tcl |
dns_60 |
Verify DNS proxy fails over when new primary DNS server is learned |
step 1. Create a new primary and backup DNS server
step 2. Terminate the WAN link and bring back up
step 3. Issue DNS query from the LAN client to the DUT's LAN IP
address
step 4. Verify LAN client receives response from new DNS servers
step 5. If DNS query fails, make additional attempts to allow
possible failover
step 6. Terminate the WAN link and bring back up with original DNS
servers
NOTE: This test is only run when the WAN mode is dynamic.
NOTE: The amount of time to wait before checking that DNS has
been updated after the WAN link is restored can be configured
using the testvar 'dnsFailoverDelay'. The default is 10 seconds.
NOTE: In IPv4 and IPv6 dual stack scenarios, the DUT may switch
over to IPv6 DNS server addresses which have not changed. These
servers are also unresponsive during the test and the DUT should
fail over to the new IPv4 DNS servers. The number of DNS queries
attempted may be configured using the testvar 'dnsFailoverAttempts'.
| Test |
Module |
Name |
Synopsis |
Verify DNS lookups with multiple IPv4 responses |
dns.tcl |
dns_70 |
Verify DNS lookups with multiple IPv4 responses |
step 1. Initiate a DNS lookup for a new unique hostname from the LAN
client to the configured DNS server
step 2. Return DNS response with multiple IPv4 answers from WAN DNS
server
step 3. Verify LAN client learns all IPv4 answers from DNS lookup
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
https://tools.ietf.org/html/rfc1035
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy recovers after DNS server outage |
dns.tcl |
dns_100 |
Verify DNS proxy recovers after DNS server outage |
step 1. Verify initial DNS lookup is working
step 2. Disable all DNS servers
step 3. Initiate 3 DNS lookups for new domains which should fail
from the LAN client to the DUT's LAN IP address
step 4. Enable all DNS servers
step 5. Verify DNS lookups start working again
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
| Test |
Module |
Name |
Synopsis |
Verify DNS queries including the EDNS0 option |
dns.tcl |
dns_110 |
Verify DNS queries including the EDNS0 option |
step 1. Initiate a DNS lookup containing EDNS0 option for a new
unique hostname from the LAN client to the configured DNS
server
step 2. Return DNS response with TTL set to 0 from WAN DNS server
step 3. Change the IP address on the DNS server for the new hostname
step 4. Initiate a new DNS lookup containing EDNS0 option for the
same hostname
step 5. Verify a new DNS request is sent to the primary or backup
DNS servers; inclusion of EDNS0 option should not affect
ability to successfully resolve hostnames
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format
https://tools.ietf.org/html/rfc1035#section-3.2.1
| Test |
Module |
Name |
Synopsis |
Verify large DNS responses using EDNS0 option |
dns.tcl |
dns_120 |
Verify large DNS responses using EDNS0 option |
step 1. Configure a DNS entry with 200 IPv4 matching records that
requires a UDP response slightly less than 4096
step 2. Initiate a DNS lookup for a new unique hostname from the LAN
client to the configured DNS server using EDNS0 option
announcing a UDP buffer size of 4096
step 3. Return DNS response with multiple IPv4 answers from WAN DNS
server
step 4. Verify LAN client learns all IPv4 answers from DNS lookup
References:
IETF RFC 6891 "Extension Mechanisms for DNS (EDNS0)"
https://tools.ietf.org/html/rfc6891
| Test |
Module |
Name |
Synopsis |
Verify maximum UDP payload value in EDNS0 option |
dns.tcl |
dns_121 |
Verify maximum UDP payload value in EDNS0 option |
step 1. Initiate a DNS lookup for a unique hostname from the LAN
client to the configured DNS server using EDNS0 option
announcing a UDP buffer size of 4096
step 2. Verify DNS response contains EDNS0 option
step 3. Configure a DNS entry with enough matching IPv4 records that
requires a UDP response slightly less than the EDNS0 UDP
buffer size seen in step 2
step 4. Initiate a DNS lookup for the same hostname from LAN client
using EDNS0 option announcing a UDP buffer size of 4096
step 5. Return DNS response with multiple IPv4 answers from WAN DNS
server
step 6. Verify LAN client learns all IPv4 answers from DNS lookup
References:
IETF RFC 6891 "Extension Mechanisms for DNS (EDNS0)"
https://tools.ietf.org/html/rfc6891
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for TXT records |
dns.tcl |
dns_130 |
Verify DNS queries for TXT records |
step 1. Initiate a DNS TXT query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS server
step 4. Send a return TXT response back to LAN
step 5. Verify the response is received by LAN client
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
https://tools.ietf.org/html/rfc1035
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for CNAME records |
dns.tcl |
dns_132 |
Verify DNS queries for CNAME records |
step 1. Initiate a DNS CNAME query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS server
step 4. Send a return CNAME response back to LAN
step 5. Verify the response is received by LAN client
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
https://tools.ietf.org/html/rfc1035
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for responses returning both CNAME and A records |
dns.tcl |
dns_133 |
Verify DNS queries for responses returning both CNAME and A records |
step 1. Initiate a DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS server
step 4. Send both a CNAME and A records response back to LAN
step 5. Verify the response is received by LAN client with both CNAME
and A records
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
https://tools.ietf.org/html/rfc1035
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for responses returning both CNAME and AAAA records |
dns.tcl |
dns_134 |
Verify DNS queries for responses returning both CNAME and AAAA records |
step 1. Initiate a DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS server
step 4. Send both a CNAME and AAAA records response back to LAN
step 5. Verify the response is received by LAN client with both CNAME
and AAAA records
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
https://tools.ietf.org/html/rfc1035
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for SPF records |
dns.tcl |
dns_140 |
Verify DNS queries for SPF records |
step 1. Initiate a DNS SPF query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return SPF response back to LAN
step 5. Verify the response is received by LAN client
References:
IETF RFC 4408 "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1"
https://tools.ietf.org/html/rfc4408
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for SRV records |
dns.tcl |
dns_141 |
Verify DNS queries for SRV records |
step 1. Initiate a DNS SRV query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return SRV response back to LAN
step 5. Verify the response is received by LAN client
step 6. Verify the response priority, weight, port and target fields
References:
IETF RFC 2782 "A DNS RR for specifying the location of services (DNS SRV)"
https://tools.ietf.org/html/rfc2782
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy behavior for DNS server status requests |
dns.tcl |
dns_150 |
Verify DNS proxy behavior for DNS server status requests |
step 1. Send a DNS server status request from the LAN client to the
configured DNS server
step 2. Verify that the DNS proxy either forwards the server status request
to the real DNS server or drops it based on the proxy's expected
behavior
NOTE: Scanning tools including Nmap utilize DNS server status requests when
probing a host. Some DNS proxy implementations will drop DNS server status
requests for security reasons. The testvar dnsForwardServerStatus should be
set to a value of **no** if this is the expected behavior of the DUT's DNS
proxy. For DNS proxy implementations that forward server status request
messages upstream, the testvar dnsForwardServerStatus should be set to a
value of **yes**.
References:
IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 3: Transparency Principle
https://tools.ietf.org/html/rfc5625#section-3
The DNS Status OPCODE Section 6: Security Considerations
http://www.eric-a-hall.com/specs/draft-hall-status-opcode-00-1.txt6
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy does not mangle DNSSEC queries |
dns.tcl |
dns_200 |
Verify DNS proxy does not mangle DNSSEC queries |
step 1. Initiate a DNSKEY query from the LAN client to the
configured DNS server
step 2. The query may be received by the primary or backup DNS
server
step 3. Send a DNSKEY response back to LAN
step 4. Verify the response is received by LAN client and all fields
are correct
step 5. Repeat steps 1-5 for RRSIG, DS, and NSEC queries
NOTE: The router must support some type of DNS relay or proxy to
pass this test case.
References:
IETF RFC 4034 "Resource Records for the DNS Security Extensions"
https://tools.ietf.org/html/rfc4034
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy does not mangle large DNSSEC responses |
dns.tcl |
dns_201 |
Verify DNS proxy does not mangle large DNSSEC responses |
step 1. Initiate a DNSKEY query from the LAN client to the
configured DNS server
step 2. The query may be received by the primary or backup DNS
server
step 3. Send a large RRSIG response (greater than 1220 bytes) back
to LAN
step 4. Verify full response is received by LAN client and all
fields are correct
NOTE: The router must support some type of DNS relay or proxy to
pass this test case.
References:
IETF RFC 4035 "Protocol Modifications for the DNS Security Extensions" Section 4.1: EDNS Support
https://tools.ietf.org/html/rfc4035#section-4.1
| Test |
Module |
Name |
Synopsis |
Verify DHCP server automatically registers DHCP client's hostname in DNS |
dns.tcl |
dns_210 |
Verify DHCP server automatically registers DHCP client’s hostname in DNS |
step 1. Perform a DNS lookup on the DHCP client's hostname on LAN
step 2. Verify DNS record exists and contains correct address
The DHCP Host Name option can be used to communicate an RFC 1035
compatible domain name to the DHCP server. This test case verifies
devices that will automatically populate the local DNS server with
this hostname entry.
References:
IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option
https://tools.ietf.org/html/rfc2132#section-3.14
| Test |
Module |
Name |
Synopsis |
Verify DHCP server updates DHCP client's hostname when it changes |
dns.tcl |
dns_220 |
Verify DHCP server updates DHCP client’s hostname when it changes |
step 1. Restart DHCP client on LAN with new hostname value
step 2. Verify DHCP client obtains IPv4 address
step 3. Perform a DNS lookup on the new DHCP client's hostname on LAN
step 4. Verify DNS record exists and contains correct address
step 5. Restore DHCP clients original hostname
The DHCP Host Name option can be used to communicate an RFC 1035
compatible domain name to the DHCP server. This test case verifies
devices that will automatically populate the local DNS server with
this hostname entry.
References:
IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option
https://tools.ietf.org/html/rfc2132#section-3.14
| Test |
Module |
Name |
Synopsis |
Verify DHCP server supports FQDN hostname values |
dns.tcl |
dns_230 |
Verify DHCP server supports FQDN hostname values |
step 1. Restart DHCP client on LAN with new FQDN hostname value
step 2. Verify DHCP client obtains IPv4 address
step 3. Perform a DNS lookup on the new DHCP client's hostname on LAN
step 4. Verify DNS record exists and contains correct address
step 5. Restore DHCP clients original hostname
The DHCP Host Name option may contain a fully qualified name.
References:
IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option
https://tools.ietf.org/html/rfc2132#section-3.14
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy removes old DHCP hostname values when hostname changes |
dns.tcl |
dns_240 |
Verify DNS proxy removes old DHCP hostname values when hostname changes |
step 1. Restart DHCP client on LAN with new hostname value
step 2. Verify DHCP client obtains IPv4 address
step 3. Perform a DNS lookup on the new DHCP client's hostname on LAN
step 4. Verify DNS record exists and contains correct address
step 5. Restart DHCP client with original hostname
step 6. Verify DHCP client obtains IPv4 address
step 7. Perform a DNS lookup on the old DHCP client's hostname on LAN
step 8. Verify the old hostname is no longer in DNS
References:
IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option
https://tools.ietf.org/html/rfc2132#section-3.14
| Test |
Module |
Name |
Synopsis |
Verify DHCP server handles DHCP hostname option with maximum size DNS subdomain length |
dns.tcl |
dns_250 |
Verify DHCP server handles DHCP hostname option with maximum size DNS subdomain length |
step 1. Restart DHCP client on LAN with new hostname value with total length of 63
step 2. Verify DHCP client obtains IPv4 address
step 3. Perform a DNS lookup on the new DHCP client's hostname on LAN
step 4. Verify DNS record exists and contains correct address
step 5. Restore DHCP clients original hostname
References:
IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option
https://tools.ietf.org/html/rfc2132#section-3.14
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy honors TTL values when caching responses |
dns.tcl |
dns_300 |
Verify DNS proxy honors TTL values when caching responses |
step 1. Initiate a DNS lookup for a hostname from the LAN client to
the DUT's LAN IP address
step 2. Verify DUT's DNS proxy forwards the query to the WAN DNS
server
step 3. Change the address on the WAN DNS server for the new
hostname
step 4. Wait half the TTL value of the response
step 5. Perform a DNS lookup on the same hostname from the LAN
step 6. If supportsDnsCaching is yes, verify DUT's DNS proxy returns
cached response from step 2 and does not forward the query
to the WAN DNS server. If supportsDnsCaching is no, verify
DUT's DNS proxy forwards the query to the WAN DNS server
step 7. Wait long enough for the TTL value of the response from
step 2 to have elapsed
step 8. Perform a DNS lookup on the same hostname from the LAN
step 9. Verify DUT's DNS proxy forwards the query to the WAN DNS
server
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 4.1.3: Resource Record Format
https://tools.ietf.org/html/rfc1035#section-4.1.3
| Test |
Module |
Name |
Synopsis |
Verify maximum number of cached DNS responses |
dns.tcl |
dns_301 |
Verify maximum number of cached DNS responses |
step 1. Initiate a DNS lookup for a new unique hostname from the LAN
client to the DUT's LAN IP address
step 2. Verify that the DUT's DNS proxy forwards the query to the
WAN DNS server
step 3. Send a valid response to the DUT on the WAN and verify that
DUT's DNS proxy forwards this response to the LAN client
step 4. Repeat steps 1 through 3 dnsCacheSize times
step 5. Repeat steps 1 through 4 but look up the hostnames in
reverse order
step 6. Verify that each hostname lookup is cached by the DUT's
DNS proxy
NOTE: The testvar dnsCacheSize should be configured to match the
minimum size of the DUT's DNS cache.
| Test |
Module |
Name |
Synopsis |
Verify parallel DNS queries |
dns.tcl |
dns_400 |
Verify parallel DNS queries |
step 1. Initiate a DNS A record lookup for a new unique hostname
from the LAN client to the configured DNS server
step 2. Initiate a DNS AAAA record lookup from the LAN client for
the same hostname used in step 1 to the configured DNS
server on the same socket as used in step 1
step 3. Verify that DNS responses are received for both DNS
queries
| Test |
Module |
Name |
Synopsis |
Verify DNS does not deploy NXDOMAIN hijacking for type A records |
dns.tcl |
dns_410 |
Verify DNS does not deploy NXDOMAIN hijacking for type A records |
step 1. Initiate a DNS lookup for a new unique type A DNS record from
the LAN client to the configured DNS server
step 2. Return DNS response with NXDOMAIN (No such domain reply code)
step 3. Verify the NXDOMAIN response is returned to the LAN client
References:
DNS NXDOMAIN Hijacking
http://en.wikipedia.org/wiki/DNS_hijacking
| Test |
Module |
Name |
Synopsis |
Verify DNS does not deploy NXDOMAIN hijacking for type AAAA records |
dns.tcl |
dns_411 |
Verify DNS does not deploy NXDOMAIN hijacking for type AAAA records |
step 1. Initiate a DNS lookup for a new unique type AAAA DNS record from
the LAN client to the configured DNS server
step 2. Return DNS response with NXDOMAIN (No such domain reply code)
step 3. Verify the NXDOMAIN response is returned to the LAN client
References:
DNS NXDOMAIN Hijacking
http://en.wikipedia.org/wiki/DNS_hijacking
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy handles use of bit 0x20 in DNS labels |
dns.tcl |
dns_420 |
Verify DNS proxy handles use of bit 0x20 in DNS labels |
step 1. Add a new DNS hostname to the DNS servers on the WAN
step 2. Create a new bit 0x20 version of the DNS hostname
step 3. Initiate a DNS lookup from the LAN client using the bit 0x20 DNS label
step 4. Verify the LAN client receives a valid DNS response
step 5. Repeat this process for 100 variations of the bit 0x20 DNS label
References:
IETF Internet-Draft draft-vixie-dnsext-dns0x20-00 "Use of Bit 0x20 in DNS Labels to Improve Transaction Identity"
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy enforces DNS strict privacy usage profile |
dns.tcl |
dns_500 |
Verify DNS proxy enforces DNS strict privacy usage profile |
step 1. Add a new DNS hostname to the DNS servers on the WAN
step 2. Initiate a DNS lookup for the new unique hostname from the LAN
client to the DUT's DNS proxy
step 3. Verify the LAN client receives a valid DNS response
step 4. Verify a new DNS request is sent to the primary or backup
DNS servers using a secure transport
References:
IETF RFC 8310 "Usage Profiles for DNS over (D)TLS" Section 5: Usage Profiles
https://tools.ietf.org/html/rfc8310#section-5
dns-tcp.tcl
DNS over TCP proxy and DNS failover related tests
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy does not cache DNS entry when DNS TTL is 0 |
dns-tcp.tcl |
dns_tcp_10 |
Verify DNS proxy does not cache DNS entry when DNS TTL is 0 |
step 1. Initiate a DNS lookup for a new unique hostname from the LAN
client to the configured DNS server
step 2. Return DNS response with TTL set to 0 from WAN DNS server
step 3. Change the IP address on the DNS server for the new hostname
step 4. Initiate a new DNS lookup for the same hostname
step 5. Verify a new DNS request is sent to the primary or backup
DNS servers
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format
https://tools.ietf.org/html/rfc1035#section-3.2.1
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy returns TTL of 0 when returned DNS TTL is 0 |
dns-tcp.tcl |
dns_tcp_11 |
Verify DNS proxy returns TTL of 0 when returned DNS TTL is 0 |
step 1. Initiate a DNS lookup for a new unique hostname from the LAN
client to the configured DNS server
step 2. Return DNS response with TTL set to 0 from WAN DNS server
step 3. Verify the returned TTL from the DNS proxy is 0
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format
https://tools.ietf.org/html/rfc1035#section-3.2.1
| Test |
Module |
Name |
Synopsis |
Verify AAAA IPv6 DNS queries to router are forwarded to real DNS server |
dns-tcp.tcl |
dns_tcp_40 |
Verify AAAA IPv6 DNS queries to router are forwarded to real DNS server |
step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return response back to LAN
step 5. Verify the response is received by LAN client
NOTE: The router must support some type of DNS relay or proxy to
pass this test case. The DNS relay or proxy must understand IPv6 DNS
type AAAA lookups.
References:
IETF RFC 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses"
https://tools.ietf.org/html/rfc4074
| Test |
Module |
Name |
Synopsis |
Verify AAAA IPv6 DNS queries can return no address for IPv6 to IPv4 failover |
dns-tcp.tcl |
dns_tcp_41 |
Verify AAAA IPv6 DNS queries can return no address for IPv6 to IPv4 failover |
step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send an empty return response back to LAN
step 5. Verify the response is received by LAN client
NOTE: The router must support some type of DNS relay or proxy to
pass this test case. The DNS relay or proxy must understand IPv6
DNS type AAAA lookups.
References:
IETF RFC 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses"
https://tools.ietf.org/html/rfc4074
| Test |
Module |
Name |
Synopsis |
Verify DNS failover when non-zero error codes are received in non-authoritative DNS response |
dns-tcp.tcl |
dns_tcp_45 |
Verify DNS failover when non-zero error codes are received in non-authoritative DNS response |
step 1. Verify DNS error codes from 1 - 15.
step 2. For each error code, send 3 DNS queries for a unique
hostname to the DUT's LAN IP address.
step 3. Verify a valid DNS response was received for all 3 DNS
queries.
step 4. Verify that all 3 DNS queries were received on the same
WAN DNS server address, known as the current primary DNS
server address.
step 5. Configure DNS queries sent to the current primary DNS
server address to return the error code, and all other DNS
server addresses to return the normal response.
step 6. All error responses from the current primary DNS server
address will have the authoritative bit not set.
step 7. Send 3 DNS queries for another unique hostname to the
DUT's LAN IP address.
step 8. Verify a valid DNS response is received if the error code
is expected to trigger DNS failover.
step 9. Verify that a DNS query was received on the current
primary DNS server address.
NOTE: Most DNS clients that support multiple DNS servers (primary and
backup) use some type of failover for certain DNS error codes. The behavior
for each error code is implementation dependent. The list of error codes
that will cause DNS failover can be configured using the testvar
'dnsFailoverAuth'. If no DNS error codes will cause failover, the testvar
should be configured with the keyword 'none'.
Example:
testvar dnsFailoverNonAuth "2 4 5"
Example with no failover support:
testvar dnsFailoverNonAuth none
NOTE: Unix OSes based on bind will normally failover if DNS error
codes 2, 4, or 5 are received. Windows based OSes will normally
failover on all DNS error codes except 3 (No Such Name).
NOTE: In most configurations the DUT will learn the IPv4 and/or IPv6
addresses of several DNS servers on the WAN. While CDRouter will Initiate
all DNS queries on the LAN over IPv4 in this test, the DUT may use any of
the DNS servers in its list (IPv4 of IPv6) for final resolution.
| Test |
Module |
Name |
Synopsis |
Verify DNS failover when non-zero error codes are received in authoritative DNS response |
dns-tcp.tcl |
dns_tcp_46 |
Verify DNS failover when non-zero error codes are received in authoritative DNS response |
step 1. Verify DNS error codes from 1 - 15.
step 2. For each error code, send 3 DNS queries for a unique
hostname to the DUT's LAN IP address.
step 3. Verify a valid DNS response was received for all 3 DNS
queries.
step 4. Verify that all 3 DNS queries were received on the same
WAN DNS server address, known as the current primary DNS
server address.
step 5. Configure DNS queries sent to the current primary DNS
server address to return the error code, and all other DNS
server addresses to return the normal response.
step 6. All error responses from the current primary DNS server
address will have the authoritative bit set.
step 7. Send 3 DNS queries for another unique hostname to the
DUT's LAN IP address.
step 8. Verify a valid DNS response is received if the error code
is expected to trigger DNS failover.
step 9. Verify that a DNS query was received on the current
primary DNS server address.
NOTE: Most DNS clients that support multiple DNS servers (primary and
backup) use some type of failover for certain DNS error codes. The behavior
for each error code is implementation dependent. The list of error codes
that will cause DNS failover can be configured using the testvar
'dnsFailoverAuth'. If no DNS error codes will cause failover, the testvar
should be configured with the keyword 'none'.
Example:
testvar dnsFailoverAuth "2 4 5"
Example with no failover support:
testvar dnsFailoverAuth none
NOTE: Unix OSes based on bind will normally failover if DNS error
codes 2, 4, or 5 are received. Windows based OSes will normally
failover on all DNS error codes except 3 (No Such Name).
NOTE: In most configurations the DUT will learn the IPv4 and/or IPv6
addresses of several DNS servers on the WAN. While CDRouter will Initiate
all DNS queries on the LAN over IPv4 in this test, the DUT may use any of
the DNS servers in its list (IPv4 of IPv6) for final resolution.
| Test |
Module |
Name |
Synopsis |
Verify Reverse PTR DNS queries to router are forwarded to real DNS server |
dns-tcp.tcl |
dns_tcp_50 |
Verify Reverse PTR DNS queries to router are forwarded to real DNS server |
step 1. Initiate a reverse DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return response back to LAN
step 5. Verify the response is received by LAN client
NOTE: The router must support some type of DNS relay or proxy to
pass this test case.
| Test |
Module |
Name |
Synopsis |
Verify Reverse AAAA IPv6 DNS queries to router are forwarded to real DNS server |
dns-tcp.tcl |
dns_tcp_51 |
Verify Reverse AAAA IPv6 DNS queries to router are forwarded to real DNS server |
step 1. Initiate a reverse AAAA IPv6 DNS query from the LAN client
to the configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return response back to LAN
step 5. Verify the response is received by LAN client
NOTE: The router must support some type of DNS relay or proxy to
pass this test case.
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy fails over when new primary DNS server is learned |
dns-tcp.tcl |
dns_tcp_60 |
Verify DNS proxy fails over when new primary DNS server is learned |
step 1. Create a new primary and backup DNS server
step 2. Terminate the WAN link and bring back up
step 3. Issue DNS query from the LAN client to the DUT's LAN IP
address
step 4. Verify LAN client receives response from new DNS servers
step 5. If DNS query fails, make additional attempts to allow
possible failover
step 6. Terminate the WAN link and bring back up with original DNS
servers
NOTE: This test is only run when the WAN mode is dynamic.
NOTE: The amount of time to wait before checking that DNS has
been updated after the WAN link is restored can be configured
using the testvar 'dnsFailoverDelay'. The default is 10 seconds.
NOTE: In IPv4 and IPv6 dual stack scenarios, the DUT may switch
over to IPv6 DNS server addresses which have not changed. These
servers are also unresponsive during the test and the DUT should
fail over to the new IPv4 DNS servers. The number of DNS queries
attempted may be configured using the testvar 'dnsFailoverAttempts'.
| Test |
Module |
Name |
Synopsis |
Verify DNS lookups with multiple IPv4 responses |
dns-tcp.tcl |
dns_tcp_70 |
Verify DNS lookups with multiple IPv4 responses |
step 1. Initiate a DNS lookup for a new unique hostname from the LAN
client to the configured DNS server
step 2. Return DNS response with multiple IPv4 answers from WAN DNS
server
step 3. Verify LAN client learns all IPv4 answers from DNS lookup
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
https://tools.ietf.org/html/rfc1035
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy recovers after DNS server outage |
dns-tcp.tcl |
dns_tcp_100 |
Verify DNS proxy recovers after DNS server outage |
step 1. Verify initial DNS lookup is working
step 2. Disable all DNS servers
step 3. Initiate 3 DNS lookups for new domains which should fail
from the LAN client to the DUT's LAN IP address
step 4. Enable all DNS servers
step 5. Verify DNS lookups start working again
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
| Test |
Module |
Name |
Synopsis |
Verify DNS queries including the EDNS0 option |
dns-tcp.tcl |
dns_tcp_110 |
Verify DNS queries including the EDNS0 option |
step 1. Initiate a DNS lookup containing EDNS0 option for a new
unique hostname from the LAN client to the configured DNS
server
step 2. Return DNS response with TTL set to 0 from WAN DNS server
step 3. Change the IP address on the DNS server for the new hostname
step 4. Initiate a new DNS lookup containing EDNS0 option for the
same hostname
step 5. Verify a new DNS request is sent to the primary or backup
DNS servers; inclusion of EDNS0 option should not affect
ability to successfully resolve hostnames
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format
https://tools.ietf.org/html/rfc1035#section-3.2.1
| Test |
Module |
Name |
Synopsis |
Verify large DNS responses using EDNS0 option |
dns-tcp.tcl |
dns_tcp_120 |
Verify large DNS responses using EDNS0 option |
step 1. Configure a DNS entry with 200 IPv4 matching records that
requires a UDP response slightly less than 4096
step 2. Initiate a DNS lookup for a new unique hostname from the LAN
client to the configured DNS server using EDNS0 option
announcing a UDP buffer size of 4096
step 3. Return DNS response with multiple IPv4 answers from WAN DNS
server
step 4. Verify LAN client learns all IPv4 answers from DNS lookup
References:
IETF RFC 6891 "Extension Mechanisms for DNS (EDNS0)"
https://tools.ietf.org/html/rfc6891
| Test |
Module |
Name |
Synopsis |
Verify maximum UDP payload value in EDNS0 option |
dns-tcp.tcl |
dns_tcp_121 |
Verify maximum UDP payload value in EDNS0 option |
step 1. Initiate a DNS lookup for a unique hostname from the LAN
client to the configured DNS server using EDNS0 option
announcing a UDP buffer size of 4096
step 2. Verify DNS response contains EDNS0 option
step 3. Configure a DNS entry with enough matching IPv4 records that
requires a UDP response slightly less than the EDNS0 UDP
buffer size seen in step 2
step 4. Initiate a DNS lookup for the same hostname from LAN client
using EDNS0 option announcing a UDP buffer size of 4096
step 5. Return DNS response with multiple IPv4 answers from WAN DNS
server
step 6. Verify LAN client learns all IPv4 answers from DNS lookup
References:
IETF RFC 6891 "Extension Mechanisms for DNS (EDNS0)"
https://tools.ietf.org/html/rfc6891
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for TXT records |
dns-tcp.tcl |
dns_tcp_130 |
Verify DNS queries for TXT records |
step 1. Initiate a DNS TXT query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS server
step 4. Send a return TXT response back to LAN
step 5. Verify the response is received by LAN client
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
https://tools.ietf.org/html/rfc1035
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for CNAME records |
dns-tcp.tcl |
dns_tcp_132 |
Verify DNS queries for CNAME records |
step 1. Initiate a DNS CNAME query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS server
step 4. Send a return CNAME response back to LAN
step 5. Verify the response is received by LAN client
Reference: RFC 1035 Domain names - implementation and specification
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for responses returning both CNAME and A records |
dns-tcp.tcl |
dns_tcp_133 |
Verify DNS queries for responses returning both CNAME and A records |
step 1. Initiate a DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS server
step 4. Send both a CNAME and A records response back to LAN
step 5. Verify the response is received by LAN client with both CNAME
and A records
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
https://tools.ietf.org/html/rfc1035
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for responses returning both CNAME and AAAA records |
dns-tcp.tcl |
dns_tcp_134 |
Verify DNS queries for responses returning both CNAME and AAAA records |
step 1. Initiate a DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS server
step 4. Send both a CNAME and AAAA records response back to LAN
step 5. Verify the response is received by LAN client with both CNAME
and AAAA records
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
https://tools.ietf.org/html/rfc1035
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for SPF records |
dns-tcp.tcl |
dns_tcp_140 |
Verify DNS queries for SPF records |
step 1. Initiate a DNS SPF query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return SPF response back to LAN
step 5. Verify the response is received by LAN client
References:
IETF RFC 4408 "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1"
https://tools.ietf.org/html/rfc4408
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for SRV records |
dns-tcp.tcl |
dns_tcp_141 |
Verify DNS queries for SRV records |
step 1. Initiate a DNS SRV query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return SRV response back to LAN
step 5. Verify the response is received by LAN client
step 6. Verify the response priority, weight, port and target fields
References:
IETF RFC 2782 "A DNS RR for specifying the location of services (DNS SRV)"
https://tools.ietf.org/html/rfc2782
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy behavior for DNS server status requests |
dns-tcp.tcl |
dns_tcp_150 |
Verify DNS proxy behavior for DNS server status requests |
step 1. Send a DNS server status request from the LAN client to the
configured DNS server
step 2. Verify that the DNS proxy either forwards the server status request
to the real DNS server or drops it based on the proxy's expected
behavior
NOTE: Scanning tools including Nmap utilize DNS server status requests when
probing a host. Some DNS proxy implementations will drop DNS server status
requests for security reasons. The testvar dnsForwardServerStatus should be
set to a value of **no** if this is the expected behavior of the DUT's DNS
proxy. For DNS proxy implementations that forward server status request
messages upstream, the testvar dnsForwardServerStatus should be set to av
alue of **yes**.
References:
IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 3: Transparency Principle
https://tools.ietf.org/html/rfc5625#section-3
The DNS Status OPCODE Section 6: Security Considerations
http://www.eric-a-hall.com/specs/draft-hall-status-opcode-00-1.txt6
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy does not mangle DNSSEC queries |
dns-tcp.tcl |
dns_tcp_200 |
Verify DNS proxy does not mangle DNSSEC queries |
step 1. Initiate a DNSKEY query from the LAN client to the
configured DNS server
step 2. The query may be received by the primary or backup DNS
server
step 3. Send a DNSKEY response back to LAN
step 4. Verify the response is received by LAN client and all fields
are correct
step 5. Repeat steps 1-5 for RRSIG, DS, and NSEC queries
NOTE: The router must support some type of DNS relay or proxy to
pass this test case.
References:
IETF RFC 4034 "Resource Records for the DNS Security Extensions"
https://tools.ietf.org/html/rfc4034
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy does not mangle large DNSSEC responses |
dns-tcp.tcl |
dns_tcp_201 |
Verify DNS proxy does not mangle large DNSSEC responses |
step 1. Initiate a DNSKEY query from the LAN client to the
configured DNS server
step 2. The query may be received by the primary or backup DNS
server
step 3. Send a large RRSIG response (greater than 1220 bytes) back
to LAN
step 4. Verify full response is received by LAN client and all
fields are correct
NOTE: The router must support some type of DNS relay or proxy to
pass this test case.
References:
IETF RFC 4035 "Protocol Modifications for the DNS Security Extensions" Section 4.1: EDNS Support
https://tools.ietf.org/html/rfc4035#section-4.1
| Test |
Module |
Name |
Synopsis |
Verify DHCP server automatically registers DHCP client's hostname in DNS |
dns-tcp.tcl |
dns_tcp_210 |
Verify DHCP server automatically registers DHCP client’s hostname in DNS |
step 1. Perform a DNS lookup on the DHCP client's hostname on LAN
step 2. Verify DNS record exists and contains correct address
The DHCP Host Name option can be used to communicate an RFC 1035
compatible domain name to the DHCP server. This test case verifies
devices that will automatically populate the local DNS server with
this hostname entry.
References:
IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option
https://tools.ietf.org/html/rfc2132#section-3.14
| Test |
Module |
Name |
Synopsis |
Verify DHCP server updates DHCP client's hostname when it changes |
dns-tcp.tcl |
dns_tcp_220 |
Verify DHCP server updates DHCP client’s hostname when it changes |
step 1. Restart DHCP client on LAN with new hostname value
step 2. Verify DHCP client obtains IPv4 address
step 3. Perform a DNS lookup on the new DHCP client's hostname on LAN
step 4. Verify DNS record exists and contains correct address
step 5. Restore DHCP clients original hostname
The DHCP Host Name option can be used to communicate an RFC 1035
compatible domain name to the DHCP server. This test case verifies
devices that will automatically populate the local DNS server with
this hostname entry.
References:
IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option
https://tools.ietf.org/html/rfc2132#section-3.14
| Test |
Module |
Name |
Synopsis |
Verify DHCP server supports FQDN hostname values |
dns-tcp.tcl |
dns_tcp_230 |
Verify DHCP server supports FQDN hostname values |
step 1. Restart DHCP client on LAN with new FQDN hostname value
step 2. Verify DHCP client obtains IPv4 address
step 3. Perform a DNS lookup on the new DHCP client's hostname on LAN
step 4. Verify DNS record exists and contains correct address
step 5. Restore DHCP clients original hostname
The DHCP Host Name option may contain a fully qualified name.
References:
IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option
https://tools.ietf.org/html/rfc2132#section-3.14
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy removes old DHCP hostname values when hostname changes |
dns-tcp.tcl |
dns_tcp_240 |
Verify DNS proxy removes old DHCP hostname values when hostname changes |
step 1. Restart DHCP client on LAN with new hostname value
step 2. Verify DHCP client obtains IPv4 address
step 3. Perform a DNS lookup on the new DHCP client's hostname on LAN
step 4. Verify DNS record exists and contains correct address
step 5. Restart DHCP client with original hostname
step 6. Verify DHCP client obtains IPv4 address
step 7. Perform a DNS lookup on the old DHCP client's hostname on LAN
step 8. Verify the old hostname is no longer in DNS
References:
IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option
https://tools.ietf.org/html/rfc2132#section-3.14
| Test |
Module |
Name |
Synopsis |
Verify DHCP server handles DHCP hostname option with maximum size DNS subdomain length |
dns-tcp.tcl |
dns_tcp_250 |
Verify DHCP server handles DHCP hostname option with maximum size DNS subdomain length |
step 1. Restart DHCP client on LAN with new hostname value with total length of 63
step 2. Verify DHCP client obtains IPv4 address
step 3. Perform a DNS lookup on the new DHCP client's hostname on LAN
step 4. Verify DNS record exists and contains correct address
step 5. Restore DHCP clients original hostname
References:
IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option
https://tools.ietf.org/html/rfc2132#section-3.14
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy honors TTL values when caching responses |
dns-tcp.tcl |
dns_tcp_300 |
Verify DNS proxy honors TTL values when caching responses |
step 1. Initiate a DNS lookup for a hostname from the LAN client to
the DUT's LAN IP address
step 2. Verify DUT's DNS proxy forwards the query to the WAN DNS
server
step 3. Change the address on the WAN DNS server for the new
hostname
step 4. Wait half the TTL value of the response
step 5. Perform a DNS lookup on the same hostname from the LAN
step 6. If supportsDnsCaching is yes, verify DUT's DNS proxy returns
cached response from step 2 and does not forward the query
to the WAN DNS server. If supportsDnsCaching is no, verify
DUT's DNS proxy forwards the query to the WAN DNS server
step 7. Wait long enough for the TTL value of the response from
step 2 to have elapsed
step 8. Perform a DNS lookup on the same hostname from the LAN
step 9. Verify DUT's DNS proxy forwards the query to the WAN DNS
server
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 4.1.3: Resource Record Format
https://tools.ietf.org/html/rfc1035#section-4.1.3
| Test |
Module |
Name |
Synopsis |
Verify maximum number of cached DNS responses |
dns-tcp.tcl |
dns_tcp_301 |
Verify maximum number of cached DNS responses |
step 1. Initiate a DNS lookup for a new unique hostname from the LAN
client to the DUT's LAN IP address
step 2. Verify that the DUT's DNS proxy forwards the query to the
WAN DNS server
step 3. Send a valid response to the DUT on the WAN and verify that
DUT's DNS proxy forwards this response to the LAN client
step 4. Repeat steps 1 through 3 (dnsCacheSize + 10) times
step 5. Repeat steps 1 through 4 but look up the hostnames in
reverse order
step 6. Verify that the last 10 hostname lookups are not cached by
the DUT's DNS proxy
NOTE: The testvar dnsCacheSize should be configured to match the
size of the DUT's DNS cache.
| Test |
Module |
Name |
Synopsis |
Verify parallel DNS queries |
dns-tcp.tcl |
dns_tcp_400 |
Verify parallel DNS queries |
step 1. Initiate a DNS A record lookup for a new unique hostname
from the LAN client to the configured DNS server.
step 2. Initiate a DNS AAAA record lookup from the LAN client for
the same hostname used in step 1 to the configured DNS
server on the same socket as used in step 1.
step 3. Verify that DNS responses are received for both DNS
queries.
| Test |
Module |
Name |
Synopsis |
Verify DNS does not deploy NXDOMAIN hijacking for type A records |
dns-tcp.tcl |
dns_tcp_410 |
Verify DNS does not deploy NXDOMAIN hijacking for type A records |
step 1. Initiate a DNS lookup for a new unique type A DNS record from
the LAN client to the configured DNS server
step 2. Return DNS response with NXDOMAIN (No such domain reply code)
step 3. Verify the NXDOMAIN response is returned to the LAN client
References:
DNS NXDOMAIN Hijacking
http://en.wikipedia.org/wiki/DNS_hijacking
| Test |
Module |
Name |
Synopsis |
Verify DNS does not deploy NXDOMAIN hijacking for type AAAA records |
dns-tcp.tcl |
dns_tcp_411 |
Verify DNS does not deploy NXDOMAIN hijacking for type AAAA records |
step 1. Initiate a DNS lookup for a new unique type AAAA DNS record from
the LAN client to the configured DNS server
step 2. Return DNS response with NXDOMAIN (No such domain reply code)
step 3. Verify the NXDOMAIN response is returned to the LAN client
References:
DNS NXDOMAIN Hijacking
http://en.wikipedia.org/wiki/DNS_hijacking
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy handles use of bit 0x20 in DNS labels |
dns-tcp.tcl |
dns_tcp_420 |
Verify DNS proxy handles use of bit 0x20 in DNS labels |
step 1. Add a new DNS hostname to the DNS servers on the WAN
step 2. Create a new bit 0x20 version of the DNS hostname
step 3. Initiate a DNS lookup from the LAN client using the bit 0x20 DNS label
step 4. Verify the LAN client receives a valid DNS response
step 5. Repeat this process for 100 variations of the bit 0x20 DNS label
References:
IETF Internet-Draft draft-vixie-dnsext-dns0x20-00 "Use of Bit 0x20 in DNS Labels to Improve Transaction Identity"
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy enforces DNS strict privacy usage profile |
dns-tcp.tcl |
dns_tcp_500 |
Verify DNS proxy enforces DNS strict privacy usage profile |
step 1. Add a new DNS hostname to the DNS servers on the WAN
step 2. Initiate a DNS lookup for the new unique hostname from the LAN
client to the DUT's DNS proxy
step 3. Verify the LAN client receives a valid DNS response
step 4. Verify a new DNS request is sent to the primary or backup
DNS servers using DNS over TLS
References:
IETF RFC 8310 "Usage Profiles for DNS over (D)TLS" Section 5: Usage Profiles
https://tools.ietf.org/html/rfc8310#section-5
dns-tls.tcl
DNS over TLS proxy and DNS failover related tests
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy does not cache DNS entry when DNS TTL is 0 |
dns-tls.tcl |
dns_tls_10 |
Verify DNS proxy does not cache DNS entry when DNS TTL is 0 |
step 1. Initiate a DNS lookup for a new unique hostname from the LAN
client to the configured DNS server
step 2. Return DNS response with TTL set to 0 from WAN DNS server
step 3. Change the IP address on the DNS server for the new hostname
step 4. Initiate a new DNS lookup for the same hostname
step 5. Verify a new DNS request is sent to the primary or backup
DNS servers
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format
https://tools.ietf.org/html/rfc1035#section-3.2.1
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy returns TTL of 0 when returned DNS TTL is 0 |
dns-tls.tcl |
dns_tls_11 |
Verify DNS proxy returns TTL of 0 when returned DNS TTL is 0 |
step 1. Initiate a DNS lookup for a new unique hostname from the LAN
client to the configured DNS server
step 2. Return DNS response with TTL set to 0 from WAN DNS server
step 3. Verify the returned TTL from the DNS proxy is 0
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format
https://tools.ietf.org/html/rfc1035#section-3.2.1
| Test |
Module |
Name |
Synopsis |
Verify AAAA IPv6 DNS queries to router are forwarded to real DNS server |
dns-tls.tcl |
dns_tls_40 |
Verify AAAA IPv6 DNS queries to router are forwarded to real DNS server |
step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return response back to LAN
step 5. Verify the response is received by LAN client
NOTE: The router must support some type of DNS relay or proxy to
pass this test case. The DNS relay or proxy must understand IPv6 DNS
type AAAA lookups.
References:
IETF RFC 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses"
https://tools.ietf.org/html/rfc4074
| Test |
Module |
Name |
Synopsis |
Verify AAAA IPv6 DNS queries can return no address for IPv6 to IPv4 failover |
dns-tls.tcl |
dns_tls_41 |
Verify AAAA IPv6 DNS queries can return no address for IPv6 to IPv4 failover |
step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send an empty return response back to LAN
step 5. Verify the response is received by LAN client
NOTE: The router must support some type of DNS relay or proxy to
pass this test case. The DNS relay or proxy must understand IPv6
DNS type AAAA lookups.
References:
IETF RFC 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses"
https://tools.ietf.org/html/rfc4074
| Test |
Module |
Name |
Synopsis |
Verify DNS failover when non-zero error codes are received in non-authoritative DNS response |
dns-tls.tcl |
dns_tls_45 |
Verify DNS failover when non-zero error codes are received in non-authoritative DNS response |
step 1. Verify DNS error codes from 1 - 15.
step 2. For each error code, send 3 DNS queries for a unique
hostname to the DUT's LAN IP address.
step 3. Verify a valid DNS response was received for all 3 DNS
queries.
step 4. Verify that all 3 DNS queries were received on the same
WAN DNS server address, known as the current primary DNS
server address.
step 5. Configure DNS queries sent to the current primary DNS
server address to return the error code, and all other DNS
server addresses to return the normal response.
step 6. All error responses from the current primary DNS server
address will have the authoritative bit not set.
step 7. Send 3 DNS queries for another unique hostname to the
DUT's LAN IP address.
step 8. Verify a valid DNS response is received if the error code
is expected to trigger DNS failover.
step 9. Verify that a DNS query was received on the current
primary DNS server address.
NOTE: Most DNS clients that support multiple DNS servers (primary and
backup) use some type of failover for certain DNS error codes. The behavior
for each error code is implementation dependent. The list of error codes
that will cause DNS failover can be configured using the testvar
'dnsFailoverAuth'. If no DNS error codes will cause failover, the testvar
should be configured with the keyword 'none'.
Example:
testvar dnsFailoverNonAuth "2 4 5"
Example with no failover support:
testvar dnsFailoverNonAuth none
NOTE: Unix OSes based on bind will normally failover if DNS error
codes 2, 4, or 5 are received. Windows based OSes will normally
failover on all DNS error codes except 3 (No Such Name).
NOTE: In most configurations the DUT will learn the IPv4 and/or IPv6
addresses of several DNS servers on the WAN. While CDRouter will Initiate
all DNS queries on the LAN over IPv4 in this test, the DUT may use any of
the DNS servers in its list (IPv4 of IPv6) for final resolution.
| Test |
Module |
Name |
Synopsis |
Verify DNS failover when non-zero error codes are received in authoritative DNS response |
dns-tls.tcl |
dns_tls_46 |
Verify DNS failover when non-zero error codes are received in authoritative DNS response |
step 1. Verify DNS error codes from 1 - 15.
step 2. For each error code, send 3 DNS queries for a unique
hostname to the DUT's LAN IP address.
step 3. Verify a valid DNS response was received for all 3 DNS
queries.
step 4. Verify that all 3 DNS queries were received on the same
WAN DNS server address, known as the current primary DNS
server address.
step 5. Configure DNS queries sent to the current primary DNS
server address to return the error code, and all other DNS
server addresses to return the normal response.
step 6. All error responses from the current primary DNS server
address will have the authoritative bit set.
step 7. Send 3 DNS queries for another unique hostname to the
DUT's LAN IP address.
step 8. Verify a valid DNS response is received if the error code
is expected to trigger DNS failover.
step 9. Verify that a DNS query was received on the current
primary DNS server address.
NOTE: Most DNS clients that support multiple DNS servers (primary and
backup) use some type of failover for certain DNS error codes. The behavior
for each error code is implementation dependent. The list of error codes
that will cause DNS failover can be configured using the testvar
'dnsFailoverAuth'. If no DNS error codes will cause failover, the testvar
should be configured with the keyword 'none'.
Example:
testvar dnsFailoverAuth "2 4 5"
Example with no failover support:
testvar dnsFailoverAuth none
NOTE: Unix OSes based on bind will normally failover if DNS error
codes 2, 4, or 5 are received. Windows based OSes will normally
failover on all DNS error codes except 3 (No Such Name).
NOTE: In most configurations the DUT will learn the IPv4 and/or IPv6
addresses of several DNS servers on the WAN. While CDRouter will Initiate
all DNS queries on the LAN over IPv4 in this test, the DUT may use any of
the DNS servers in its list (IPv4 of IPv6) for final resolution.
| Test |
Module |
Name |
Synopsis |
Verify Reverse PTR DNS queries to router are forwarded to real DNS server |
dns-tls.tcl |
dns_tls_50 |
Verify Reverse PTR DNS queries to router are forwarded to real DNS server |
step 1. Initiate a reverse DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return response back to LAN
step 5. Verify the response is received by LAN client
NOTE: The router must support some type of DNS relay or proxy to
pass this test case.
| Test |
Module |
Name |
Synopsis |
Verify Reverse AAAA IPv6 DNS queries to router are forwarded to real DNS server |
dns-tls.tcl |
dns_tls_51 |
Verify Reverse AAAA IPv6 DNS queries to router are forwarded to real DNS server |
step 1. Initiate a reverse AAAA IPv6 DNS query from the LAN client
to the configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return response back to LAN
step 5. Verify the response is received by LAN client
NOTE: The router must support some type of DNS relay or proxy to
pass this test case.
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy fails over when new primary DNS server is learned |
dns-tls.tcl |
dns_tls_60 |
Verify DNS proxy fails over when new primary DNS server is learned |
step 1. Create a new primary and backup DNS server
step 2. Terminate the WAN link and bring back up
step 3. Issue DNS query from the LAN client to the DUT's LAN IP
address
step 4. Verify LAN client receives response from new DNS servers
step 5. If DNS query fails, make additional attempts to allow
possible failover
step 6. Terminate the WAN link and bring back up with original DNS
servers
NOTE: This test is only run when the WAN mode is dynamic.
NOTE: The amount of time to wait before checking that DNS has
been updated after the WAN link is restored can be configured
using the testvar 'dnsFailoverDelay'. The default is 10 seconds.
NOTE: In IPv4 and IPv6 dual stack scenarios, the DUT may switch
over to IPv6 DNS server addresses which have not changed. These
servers are also unresponsive during the test and the DUT should
fail over to the new IPv4 DNS servers. The number of DNS queries
attempted may be configured using the testvar 'dnsFailoverAttempts'.
| Test |
Module |
Name |
Synopsis |
Verify DNS lookups with multiple IPv4 responses |
dns-tls.tcl |
dns_tls_70 |
Verify DNS lookups with multiple IPv4 responses |
step 1. Initiate a DNS lookup for a new unique hostname from the LAN
client to the configured DNS server
step 2. Return DNS response with multiple IPv4 answers from WAN DNS
server
step 3. Verify LAN client learns all IPv4 answers from DNS lookup
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
https://tools.ietf.org/html/rfc1035
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy recovers after DNS server outage |
dns-tls.tcl |
dns_tls_100 |
Verify DNS proxy recovers after DNS server outage |
step 1. Verify initial DNS lookup is working
step 2. Disable all DNS servers
step 3. Initiate 3 DNS lookups for new domains which should fail
from the LAN client to the DUT's LAN IP address
step 4. Enable all DNS servers
step 5. Verify DNS lookups start working again
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
| Test |
Module |
Name |
Synopsis |
Verify DNS queries including the EDNS0 option |
dns-tls.tcl |
dns_tls_110 |
Verify DNS queries including the EDNS0 option |
step 1. Initiate a DNS lookup containing EDNS0 option for a new
unique hostname from the LAN client to the configured DNS
server
step 2. Return DNS response with TTL set to 0 from WAN DNS server
step 3. Change the IP address on the DNS server for the new hostname
step 4. Initiate a new DNS lookup containing EDNS0 option for the
same hostname
step 5. Verify a new DNS request is sent to the primary or backup
DNS servers; inclusion of EDNS0 option should not affect
ability to successfully resolve hostnames
NOTE: Zero values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be cached.
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format
https://tools.ietf.org/html/rfc1035#section-3.2.1
| Test |
Module |
Name |
Synopsis |
Verify large DNS responses using EDNS0 option |
dns-tls.tcl |
dns_tls_120 |
Verify large DNS responses using EDNS0 option |
step 1. Configure a DNS entry with 200 IPv4 matching records that
requires a UDP response slightly less than 4096
step 2. Initiate a DNS lookup for a new unique hostname from the LAN
client to the configured DNS server using EDNS0 option
announcing a UDP buffer size of 4096
step 3. Return DNS response with multiple IPv4 answers from WAN DNS
server
step 4. Verify LAN client learns all IPv4 answers from DNS lookup
References:
IETF RFC 6891 "Extension Mechanisms for DNS (EDNS0)"
https://tools.ietf.org/html/rfc6891
| Test |
Module |
Name |
Synopsis |
Verify maximum UDP payload value in EDNS0 option |
dns-tls.tcl |
dns_tls_121 |
Verify maximum UDP payload value in EDNS0 option |
step 1. Initiate a DNS lookup for a unique hostname from the LAN
client to the configured DNS server using EDNS0 option
announcing a UDP buffer size of 4096
step 2. Verify DNS response contains EDNS0 option
step 3. Configure a DNS entry with enough matching IPv4 records that
requires a UDP response slightly less than the EDNS0 UDP
buffer size seen in step 2
step 4. Initiate a DNS lookup for the same hostname from LAN client
using EDNS0 option announcing a UDP buffer size of 4096
step 5. Return DNS response with multiple IPv4 answers from WAN DNS
server
step 6. Verify LAN client learns all IPv4 answers from DNS lookup
References:
IETF RFC 6891 "Extension Mechanisms for DNS (EDNS0)"
https://tools.ietf.org/html/rfc6891
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for TXT records |
dns-tls.tcl |
dns_tls_130 |
Verify DNS queries for TXT records |
step 1. Initiate a DNS TXT query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS server
step 4. Send a return TXT response back to LAN
step 5. Verify the response is received by LAN client
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
https://tools.ietf.org/html/rfc1035
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for CNAME records |
dns-tls.tcl |
dns_tls_132 |
Verify DNS queries for CNAME records |
step 1. Initiate a DNS CNAME query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS server
step 4. Send a return CNAME response back to LAN
step 5. Verify the response is received by LAN client
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
https://tools.ietf.org/html/rfc1035
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for responses returning both CNAME and A records |
dns-tls.tcl |
dns_tls_133 |
Verify DNS queries for responses returning both CNAME and A records |
step 1. Initiate a DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS server
step 4. Send both a CNAME and A records response back to LAN
step 5. Verify the response is received by LAN client with both CNAME
and A records
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
https://tools.ietf.org/html/rfc1035
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for responses returning both CNAME and AAAA records |
dns-tls.tcl |
dns_tls_134 |
Verify DNS queries for responses returning both CNAME and AAAA records |
step 1. Initiate a DNS query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS server
step 4. Send both a CNAME and AAAA records response back to LAN
step 5. Verify the response is received by LAN client with both CNAME
and AAAA records
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
https://tools.ietf.org/html/rfc1035
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for SPF records |
dns-tls.tcl |
dns_tls_140 |
Verify DNS queries for SPF records |
step 1. Initiate a DNS SPF query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return SPF response back to LAN
step 5. Verify the response is received by LAN client
References:
IETF RFC 4408 "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1"
https://tools.ietf.org/html/rfc4408
| Test |
Module |
Name |
Synopsis |
Verify DNS queries for SRV records |
dns-tls.tcl |
dns_tls_141 |
Verify DNS queries for SRV records |
step 1. Initiate a DNS SRV query from the LAN client to the
configured DNS server
step 2. Verify the query is received by real DNS server on the WAN
side
step 3. The query may be received by the primary or backup DNS
server
step 4. Send a return SRV response back to LAN
step 5. Verify the response is received by LAN client
step 6. Verify the response priority, weight, port and target fields
References:
IETF RFC 2782 "A DNS RR for specifying the location of services (DNS SRV)"
https://tools.ietf.org/html/rfc2782
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy behavior for DNS server status requests |
dns-tls.tcl |
dns_tls_150 |
Verify DNS proxy behavior for DNS server status requests |
step 1. Send a DNS server status request from the LAN client to the
configured DNS server
step 2. Verify that the DNS proxy either forwards the server status request
to the real DNS server or drops it based on the proxy's expected
behavior
NOTE: Scanning tools including Nmap utilize DNS server status requests when
probing a host. Some DNS proxy implementations will drop DNS server status
requests for security reasons. The testvar dnsForwardServerStatus should be
set to a value of **no** if this is the expected behavior of the DUT's DNS
proxy. For DNS proxy implementations that forward server status request
messages upstream, the testvar dnsForwardServerStatus should be set to av
alue of **yes**.
References:
IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 3: Transparency Principle
https://tools.ietf.org/html/rfc5625#section-3
The DNS Status OPCODE Section 6: Security Considerations
http://www.eric-a-hall.com/specs/draft-hall-status-opcode-00-1.txt6
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy does not mangle DNSSEC queries |
dns-tls.tcl |
dns_tls_200 |
Verify DNS proxy does not mangle DNSSEC queries |
step 1. Initiate a DNSKEY query from the LAN client to the
configured DNS server
step 2. The query may be received by the primary or backup DNS
server
step 3. Send a DNSKEY response back to LAN
step 4. Verify the response is received by LAN client and all fields
are correct
step 5. Repeat steps 1-5 for RRSIG, DS, and NSEC queries
NOTE: The router must support some type of DNS relay or proxy to
pass this test case.
References:
IETF RFC 4034 "Resource Records for the DNS Security Extensions"
https://tools.ietf.org/html/rfc4034
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy does not mangle large DNSSEC responses |
dns-tls.tcl |
dns_tls_201 |
Verify DNS proxy does not mangle large DNSSEC responses |
step 1. Initiate a DNSKEY query from the LAN client to the
configured DNS server
step 2. The query may be received by the primary or backup DNS
server
step 3. Send a large RRSIG response (greater than 1220 bytes) back
to LAN
step 4. Verify full response is received by LAN client and all
fields are correct
NOTE: The router must support some type of DNS relay or proxy to
pass this test case.
References:
IETF RFC 4035 "Protocol Modifications for the DNS Security Extensions" Section 4.1: EDNS Support
https://tools.ietf.org/html/rfc4035#section-4.1
| Test |
Module |
Name |
Synopsis |
Verify DHCP server automatically registers DHCP client's hostname in DNS |
dns-tls.tcl |
dns_tls_210 |
Verify DHCP server automatically registers DHCP client’s hostname in DNS |
step 1. Perform a DNS lookup on the DHCP client's hostname on LAN
step 2. Verify DNS record exists and contains correct address
The DHCP Host Name option can be used to communicate an RFC 1035
compatible domain name to the DHCP server. This test case verifies
devices that will automatically populate the local DNS server with
this hostname entry.
References:
IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option
https://tools.ietf.org/html/rfc2132#section-3.14
| Test |
Module |
Name |
Synopsis |
Verify DHCP server updates DHCP client's hostname when it changes |
dns-tls.tcl |
dns_tls_220 |
Verify DHCP server updates DHCP client’s hostname when it changes |
step 1. Restart DHCP client on LAN with new hostname value
step 2. Verify DHCP client obtains IPv4 address
step 3. Perform a DNS lookup on the new DHCP client's hostname on LAN
step 4. Verify DNS record exists and contains correct address
step 5. Restore DHCP clients original hostname
The DHCP Host Name option can be used to communicate an RFC 1035
compatible domain name to the DHCP server. This test case verifies
devices that will automatically populate the local DNS server with
this hostname entry.
References:
IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option
https://tools.ietf.org/html/rfc2132#section-3.14
| Test |
Module |
Name |
Synopsis |
Verify DHCP server supports FQDN hostname values |
dns-tls.tcl |
dns_tls_230 |
Verify DHCP server supports FQDN hostname values |
step 1. Restart DHCP client on LAN with new FQDN hostname value
step 2. Verify DHCP client obtains IPv4 address
step 3. Perform a DNS lookup on the new DHCP client's hostname on LAN
step 4. Verify DNS record exists and contains correct address
step 5. Restore DHCP clients original hostname
The DHCP Host Name option may contain a fully qualified name.
References:
IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option
https://tools.ietf.org/html/rfc2132#section-3.14
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy removes old DHCP hostname values when hostname changes |
dns-tls.tcl |
dns_tls_240 |
Verify DNS proxy removes old DHCP hostname values when hostname changes |
step 1. Restart DHCP client on LAN with new hostname value
step 2. Verify DHCP client obtains IPv4 address
step 3. Perform a DNS lookup on the new DHCP client's hostname on LAN
step 4. Verify DNS record exists and contains correct address
step 5. Restart DHCP client with original hostname
step 6. Verify DHCP client obtains IPv4 address
step 7. Perform a DNS lookup on the old DHCP client's hostname on LAN
step 8. Verify the old hostname is no longer in DNS
References:
IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option
https://tools.ietf.org/html/rfc2132#section-3.14
| Test |
Module |
Name |
Synopsis |
Verify DHCP server handles DHCP hostname option with maximum size DNS subdomain length |
dns-tls.tcl |
dns_tls_250 |
Verify DHCP server handles DHCP hostname option with maximum size DNS subdomain length |
step 1. Restart DHCP client on LAN with new hostname value with total length of 63
step 2. Verify DHCP client obtains IPv4 address
step 3. Perform a DNS lookup on the new DHCP client's hostname on LAN
step 4. Verify DNS record exists and contains correct address
step 5. Restore DHCP clients original hostname
References:
IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option
https://tools.ietf.org/html/rfc2132#section-3.14
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy honors TTL values when caching responses |
dns-tls.tcl |
dns_tls_300 |
Verify DNS proxy honors TTL values when caching responses |
step 1. Initiate a DNS lookup for a hostname from the LAN client to
the DUT's LAN IP address
step 2. Verify DUT's DNS proxy forwards the query to the WAN DNS
server
step 3. Change the address on the WAN DNS server for the new
hostname
step 4. Wait half the TTL value of the response
step 5. Perform a DNS lookup on the same hostname from the LAN
step 6. If supportsDnsCaching is yes, verify DUT's DNS proxy returns
cached response from step 2 and does not forward the query
to the WAN DNS server. If supportsDnsCaching is no, verify
DUT's DNS proxy forwards the query to the WAN DNS server
step 7. Wait long enough for the TTL value of the response from
step 2 to have elapsed
step 8. Perform a DNS lookup on the same hostname from the LAN
step 9. Verify DUT's DNS proxy forwards the query to the WAN DNS
server
References:
IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 4.1.3: Resource Record Format
https://tools.ietf.org/html/rfc1035#section-4.1.3
| Test |
Module |
Name |
Synopsis |
Verify maximum number of cached DNS responses |
dns-tls.tcl |
dns_tls_301 |
Verify maximum number of cached DNS responses |
step 1. Initiate a DNS lookup for a new unique hostname from the LAN
client to the DUT's LAN IP address
step 2. Verify that the DUT's DNS proxy forwards the query to the
WAN DNS server
step 3. Send a valid response to the DUT on the WAN and verify that
DUT's DNS proxy forwards this response to the LAN client
step 4. Repeat steps 1 through 3 (dnsCacheSize + 10) times
step 5. Repeat steps 1 through 4 but look up the hostnames in
reverse order
step 6. Verify that the last 10 hostname lookups are not cached by
the DUT's DNS proxy
NOTE: The testvar dnsCacheSize should be configured to match the
size of the DUT's DNS cache.
| Test |
Module |
Name |
Synopsis |
Verify parallel DNS queries |
dns-tls.tcl |
dns_tls_400 |
Verify parallel DNS queries |
step 1. Initiate a DNS A record lookup for a new unique hostname
from the LAN client to the configured DNS server.
step 2. Initiate a DNS AAAA record lookup from the LAN client for
the same hostname used in step 1 to the configured DNS
server on the same socket as used in step 1.
step 3. Verify that DNS responses are received for both DNS
queries.
| Test |
Module |
Name |
Synopsis |
Verify DNS does not deploy NXDOMAIN hijacking for type A records |
dns-tls.tcl |
dns_tls_410 |
Verify DNS does not deploy NXDOMAIN hijacking for type A records |
step 1. Initiate a DNS lookup for a new unique type A DNS record from
the LAN client to the configured DNS server
step 2. Return DNS response with NXDOMAIN (No such domain reply code)
step 3. Verify the NXDOMAIN response is returned to the LAN client
NXDOMAIN hijacking is used to modify negative DNS responses. It
is generally considered poor form and may break DNS services that
depend on receiving NXDOMAIN responses.
References:
DNS NXDOMAIN Hijacking
http://en.wikipedia.org/wiki/DNS_hijacking
| Test |
Module |
Name |
Synopsis |
Verify DNS does not deploy NXDOMAIN hijacking for type AAAA records |
dns-tls.tcl |
dns_tls_411 |
Verify DNS does not deploy NXDOMAIN hijacking for type AAAA records |
step 1. Initiate a DNS lookup for a new unique type AAAA DNS record from
the LAN client to the configured DNS server
step 2. Return DNS response with NXDOMAIN (No such domain reply code)
step 3. Verify the NXDOMAIN response is returned to the LAN client
NXDOMAIN hijacking is used to modify negative DNS responses. It
is generally considered poor form and may break DNS services that
depend on receiving NXDOMAIN responses.
References:
DNS NXDOMAIN Hijacking
http://en.wikipedia.org/wiki/DNS_hijacking
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy handles use of bit 0x20 in DNS labels |
dns-tls.tcl |
dns_tls_420 |
Verify DNS proxy handles use of bit 0x20 in DNS labels |
step 1. Add a new DNS hostname to the DNS servers on the WAN
step 2. Create a new bit 0x20 version of the DNS hostname
step 3. Initiate a DNS lookup from the LAN client using the bit 0x20 DNS label
step 4. Verify the LAN client receives a valid DNS response
step 5. Repeat this process for 100 variations of the bit 0x20 DNS label
References:
IETF Internet-Draft draft-vixie-dnsext-dns0x20-00 "Use of Bit 0x20 in DNS Labels to Improve Transaction Identity"
https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00
| Test |
Module |
Name |
Synopsis |
Verify DNS proxy enforces DNS strict privacy usage profile |
dns-tls.tcl |
dns_tls_500 |
Verify DNS proxy enforces DNS strict privacy usage profile |
step 1. Add a new DNS hostname to the DNS servers on the WAN
step 2. Initiate a DNS lookup for the new unique hostname from the LAN
client to the DUT's DNS proxy
step 3. Verify the LAN client receives a valid DNS response
step 4. Verify a new DNS request is sent to the primary or backup
DNS servers using DNS over TLS
References:
IETF RFC 8310 "Usage Profiles for DNS over (D)TLS" Section 5: Usage Profiles
https://tools.ietf.org/html/rfc8310#section-5
mdns.tcl
mDNS related test cases
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to mDNS query of its hostname |
mdns.tcl |
mdns_10 |
Verify DUT responds to mDNS query of its hostname |
step 1. Initiate a one-shot mDNS query from the LAN for the A
record of the DUT's LAN hostname in the top-level domain
'local'.
step 2. Verify the mDNS query succeeds and the response contains
the DUT's LAN address.
NOTE: The DUT's expected LAN hostname is taken from the testvar
lanHostname.
References:
IETF RFC 6762 "Multicast DNS"
https://tools.ietf.org/html/rfc6762
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to mDNS reverse query of its LAN IP |
mdns.tcl |
mdns_11 |
Verify DUT responds to mDNS reverse query of its LAN IP |
step 1. Initiate a on-shot mDNS query from the LAN for the reverse
mapping of the DUT's LAN address.
step 2. Verify the mDNS query succeeds and the response contains
the DUT's LAN hostname in the top-level domain 'local'.
NOTE: The DUT's expected LAN hostname is taken from the testvar
lanHostname.
References:
IETF RFC 6762 "Multicast DNS"
https://tools.ietf.org/html/rfc6762
| Test |
Module |
Name |
Synopsis |
Verify DUT returns DNS-Service Discovery records for its web server |
mdns.tcl |
mdns_12 |
Verify DUT returns DNS-Service Discovery records for its web server |
step 1. Initiate a one-shot mDNS query from the LAN for the DUT's
_services._dns-sd._udp.local PTR record.
step 2. Verify that the mDNS query succeeds and the response
contains the _http._tcp.local domain.
step 3. Initiate a one-shot mDNS query from the LAN for the DUT's
_http._tcp.local PTR record.
step 4. Verify that mDNS query succeeds.
step 5. Initiate a one-shot mDNS query from the LAN for the
SRV record of the resource returned in step 4.
step 6. Verify that the mDNS query succeeds and the response
contains the DUT's management port and the domain
LANHOSTNAME.local.
step 7. Initiate a one-shot mDNS query from the LAN for the A
record of LANHOSTNAME.local.
step 8. Verify that the mDNS query succeeds and the response
contains the DUT's LAN address.
step 9. Initiate an HTTP GET of the URL http://LANHOSTNAME:80 from
the LAN.
step 10. Verify that the HTTP GET succeeds.
NOTE: The value of LANHOSTNAME is taken from the value of the
lanHostname testvar.
NOTE: The value of the DUT's management port is taken from the
default insecure management port defined as the first port
in the value of testvar dutMgmtPort. Please read the
documentation for dutMgmtPort for more information about the
default insecure management port concept and its usage.
References:
IETF RFC 6762 "Multicast DNS"
https://tools.ietf.org/html/rfc6762
IETF RFC 6763 "DNS-Based Service Discovery"
https://tools.ietf.org/html/rfc6763
| Test |
Module |
Name |
Synopsis |
Verify DUT does not forward LAN mDNS query onto the WAN |
mdns.tcl |
mdns_13 |
Verify DUT does not forward LAN mDNS query onto the WAN |
step 1. Initiate a one-shot mDNS query from the LAN destined for
IPv4 multicast local network control block address
224.0.0.251.
step 2. Verify that the mDNS query is not forwarded on the WAN.
References:
IETF RFC 6762 "Multicast DNS"
https://tools.ietf.org/html/rfc6762
IETF RFC 5771 "IANA Guidelines for IPv4 Multicast Address Assignments" Section 4: Local Network Control Block (224.0.0/24)
https://tools.ietf.org/html/rfc5771#section-4
dns-rfc5625.tcl
IETF RFC 5625 DNS Proxy Implementation Guidelines
| Test |
Module |
Name |
Synopsis |
A DNS proxy must forward unknown DNS flags and data |
dns-rfc5625.tcl |
dns_rfc5625_10 |
A DNS proxy must forward unknown DNS flags and data |
step 1. Initiate a new DNS lookup for a new unique hostname from LAN client
step 2. Return DNS response with Z flag set to 1
step 3. Verify the DNS packet is received by the LAN client
References:
IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 4.1: Unexpected Flags and Data
https://tools.ietf.org/html/rfc5625#section-4.1
| Test |
Module |
Name |
Synopsis |
A DNS proxy must forward DNS packets regardless of compressed labels |
dns-rfc5625.tcl |
dns_rfc5625_11 |
A DNS proxy must forward DNS packets regardless of compressed labels |
step 1. Forward a DNS query to the DUT's DNS forwarder that will generate
a DNS reply with multiple answers using compression labels
step 2. Verify that the DNS reply uses compression labels.
References:
IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 4.2: Label Compression
https://tools.ietf.org/html/rfc5625#section-4.2
| Test |
Module |
Name |
Synopsis |
A DNS proxy must forward DNS packets regardless of qtype and qclass fields |
dns-rfc5625.tcl |
dns_rfc5625_12 |
A DNS proxy must forward DNS packets regardless of qtype and qclass fields |
step 1. Initiate a DNS lookup using an UNKNOWN class type
step 2. Return DNS response with an UNKNOWN class type from WAN DNS Server
step 3. Verify the DNS packet is received by the LAN client
References:
IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 4.3: Unknown Resource Record Types
https://tools.ietf.org/html/rfc5625#section-4.3
| Test |
Module |
Name |
Synopsis |
A DNS proxy must always preserve the TC bit |
dns-rfc5625.tcl |
dns_rfc5625_13 |
A DNS proxy must always preserve the TC bit |
step 1. Send a DNS request via the DNS proxy that will solicit
a response that artificially has the TC bit set.
step 2. Verify that the DNS packet is received by the LAN client
and that the proxy has not reset the TC bit
NOTE: Section 4.4 of RFC 5625 covers several scenarios in which the DNS
proxy can incorrectly strip the TC (TrunCated) bit. The proxy may truncate
the response, or may not, but regardless it must not interfere with a TC bit
that has already been set to 1.
References:
IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 4.4: Packet Size Limits
https://tools.ietf.org/html/rfc5625#section-4.4
| Test |
Module |
Name |
Synopsis |
A DNS proxy must be able to forward DNS over TCP |
dns-rfc5625.tcl |
dns_rfc5625_14 |
A DNS proxy must be able to forward DNS over TCP |
step 1. Force the LAN client to send a DNS request over TCP to the DUT DNS proxy.
step 2. Verify that the upstream DNS reply is returned by the DNS proxy to the lan client.
References:
IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 4.4.1: TCP Transport
https://tools.ietf.org/html/rfc5625#section-4.4.1
| Test |
Module |
Name |
Synopsis |
A DNS proxy should not convert a TCP lookup into a UDP lookup |
dns-rfc5625.tcl |
dns_rfc5625_15 |
A DNS proxy should not convert a TCP lookup into a UDP lookup |
step 1. Send a TCP DNS request via the DUT DNS proxy.
step 2. Verify the DUT did not convert the original TCP DNS query to UDP
References:
IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 4.4.1: TCP Transport
https://tools.ietf.org/html/rfc5625#section-4.4.1
| Test |
Module |
Name |
Synopsis |
A DNS proxy should be able to forward EDNS0 UDP packets at least 4096 bytes in size |
dns-rfc5625.tcl |
dns_rfc5625_17 |
A DNS proxy should be able to forward EDNS0 UDP packets at least 4096 bytes in size |
step 1. Configure a DNS entry with 200 IPv4 matching records that
requires a UDP response slightly less than 4096
step 2. Initiate a DNS lookup for a new unique hostname from LAN client
using EDNS0 option announcing a UDP buffer size of 4096
step 3. Return DNS response with multiple IPv4 answers from WAN DNS server
step 4. Verify LAN client learns all IPv4 answers from DNS lookup
References:
IETF RFC 2671 "Extension Mechanisms for DNS (EDNS0)"
https://tools.ietf.org/html/rfc2671
IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 4.4.3: IP Fragmentation
https://tools.ietf.org/html/rfc5625#section-4.4.3
| Test |
Module |
Name |
Synopsis |
A LAN Client should be able to send a DNS query directly to upstream server |
dns-rfc5625.tcl |
dns_rfc5625_19 |
A LAN Client should be able to send a DNS query directly to upstream server |
step 1. Send a DNS query of any variety directly from the LAN client to the remote
DNS server
step 2. Verify the Query ID is the same as the one sent by the LAN client
References:
IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 5.1: Domain Name Server (DHCP Option 6)
https://tools.ietf.org/html/rfc5625#section-5.1
| Test |
Module |
Name |
Synopsis |
A DNS query ID from a DNS proxy should not increase monotonically |
dns-rfc5625.tcl |
dns_rfc5625_22 |
A DNS query ID from a DNS proxy should not increase monotonically |
step 1. Send two DNS queries upstream from the LAN client to the DNS proxy
step 2. Inspect the Query IDs created by the DNS Proxy. Verify they are non-sequential
References:
IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 6.1: Forgery Resilience
https://tools.ietf.org/html/rfc5625#section-6.1
| Test |
Module |
Name |
Synopsis |
A DNS proxy should not accept connections on the WAN port |
dns-rfc5625.tcl |
dns_rfc5625_23 |
A DNS proxy should not accept connections on the WAN port |
step 1. Send a DNS query from a WAN client to the WAN interface of the DUT
step 2. Verify that a response is not received
References:
IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 6.2: Interface Binding
https://tools.ietf.org/html/rfc5625#section-6.2
static.tcl
IP static route related tests
| Test |
Module |
Name |
Synopsis |
Verify all LAN static routes with LAN side traffic only |
static.tcl |
static_1 |
Verify all LAN static routes with LAN side traffic only |
step 1. Find all configured static routes with next hops on the LAN
interface
step 2. Create new gateways for each next hop on the LAN
step 3. Send ICMP Echo Request to a host within the static route from the
LAN host
step 4. Verify that the host in the static route reponds with ICMP Echo
Reply
| Test |
Module |
Name |
Synopsis |
Verify all LAN static routes with LAN to WAN traffic |
static.tcl |
static_2 |
Verify all LAN static routes with LAN to WAN traffic |
step 1. Find all configured static routes with next hops on the LAN
interface
step 2. Create new gateways for each nexthop on the LAN
step 3. Send ICMP Echo Request from host in static route network to the WAN
side remoteHost
step 4. Verify that the remoteHost on the WAN receives the ICMP Echo Request
step 5. Verify the WAN host ICMP Echo Reply is received by the host in
static route network
| Test |
Module |
Name |
Synopsis |
Verify all WAN static routes |
static.tcl |
static_10 |
Verify all WAN static routes |
step 1. Find all configured static routes with next hops on the WAN
interface
step 2. Create new gateways for each next hop on the WAN if not the wanIspIp
step 3. Send ICMP Echo Request to a host within the static route from the
LAN host
step 4. Verify that the host in the static route receives the ICMP Echo
Request
| Test |
Module |
Name |
Synopsis |
Verify all WAN static routes after WAN ISP address change |
static.tcl |
static_20 |
Verify all WAN static routes after WAN ISP address change |
step 1. Find all configured static routes with next hops on the WAN
interface
step 2. Create new gateways for each next hop on the WAN if not the wanIspIp
step 3. Send an ICMP Echo Request to a host within the static route from the
LAN host
step 4. Verify that the host in the static route reponds with ICMP Echo
Reply
step 5. Change CDRouter's WAN ISP address and update the DUT to use it as the
default router.
step 6. Send an ICMP Echo Request to a host within the static route from the
LAN host
NOTE: This test is intended to test static routes that are configured on the CPE
device by specifying a next hop address of "WAN" instead of a specific IP address.
Most CPEs allow this type of static route configuration since the actual next hop will
not be known during configuration when running a dynamic WAN protocol such as PPPoE,
PPTP, L2TP, or DHCP.
NOTE: This test is only run when the WAN protocol is dynamic.
dos.tcl
Common denial of service attacks against routers
| Test |
Module |
Name |
Synopsis |
Send 'ping of death' ICMP request to LAN side of the router |
dos.tcl |
cdrouter_dos_1 |
Send ‘ping of death’ ICMP request to LAN side of the router |
step 1. Initiate 'ping of death' packets to the router from the LAN side
step 2. After recovery time, verify connectivity from LAN to WAN is still working
by running test case cdrouter_nat_1 and cdrouter_nat_2
NOTE: The amount of recovery time after the ping attack can be configured
using the testvar 'dosRecoveryTime'. The default recovery time is 5 seconds.
Example:
testvar dosRecoveryTime 5
| Test |
Module |
Name |
Synopsis |
Send 'ping of death' ICMP request to WAN side of the router |
dos.tcl |
cdrouter_dos_2 |
Send ‘ping of death’ ICMP request to WAN side of the router |
step 1. Initiate 'ping of death' packets to the router from the WAN side
step 2. After recovery time, verify connectivity from LAN to WAN is still working
by running test case cdrouter_nat_1 and cdrouter_nat_2
NOTE: The amount of recovery time after the ping attack can be configured
using the testvar 'dosRecoveryTime'. The default recovery time is 5 seconds.
Example:
testvar dosRecoveryTime 5
| Test |
Module |
Name |
Synopsis |
Launch LAND attack against router's management port on the LAN |
dos.tcl |
cdrouter_dos_10 |
Launch LAND attack against router’s management port on the LAN |
step 1. Initiate LAND attack by sending TCP SYN packets to the CPE device
management port using the device's IP as the source and destination
address and using the device's MAC address as source and destination MAC.
step 2. After recovery time, verify connectivity from LAN to WAN is still working
by running test case cdrouter_nat_1 and cdrouter_nat_2.
NOTE: The amount of recovery time after the LAND attack can be configured
using the testvar 'dosRecoveryTime'. The default recovery time is 5 seconds.
The devices management port and number of attack attempts can also be configured.
Example:
testvar dosRecoveryTime 5
testvar dosAttackAttempts 100
testvar dutMgmtPort 80
NOTE: The value of the router's management port is taken from the
default insecure management port defined as the first port
in the value of testvar dutMgmtPort. Please read the
documentation for dutMgmtPort for more information about the
default insecure management port concept and its usage.
| Test |
Module |
Name |
Synopsis |
Verify that the DUT is not a Smurf reflector (ICMP attack) |
dos.tcl |
cdrouter_dos_20 |
Verify that the DUT is not a Smurf reflector (ICMP attack) |
step 1. Send broadcast ICMP Echo Requests (pings) to the router's LAN port
step 2. Verify that that the router's LAN interface does not respond to the broadcast pings
step 3. Send broadcast ICMP Echo Requests (pings) to the router's WAN port
step 4. Verify that that the router's WAN interface does not respond to the broadcast pings
step 5. Simulate a Smurf attack on the LAN by sending spoofed broadcast ICMP Echo Request
packets using the remoteHostIp as the source address
step 6. Verify that the router does not forward the Smurf packets from LAN to WAN
step 7. After recovery time, verify connectivity from LAN to WAN is still working
by running test case cdrouter_nat_1 and cdrouter_nat_2
NOTE: A Smurf attack involves sending a large number of ICMP Echo Requests to
broadcast addresses from a spoofed source address. The spoofed source address
is the address of the intended attack target. This attack can cause the target
to be flooded with ICMP Echo replies creating a denial of service situation.
Smurf attacks can be suppressed by configuring devices not to respond to broadcast
pings, and configuring routers on a network not to forward packets to broadcast
addresses.
| Test |
Module |
Name |
Synopsis |
Verify that the DUT is not a Fraggle reflector (UDP attack) |
dos.tcl |
cdrouter_dos_21 |
Verify that the DUT is not a Fraggle reflector (UDP attack) |
step 1. Send UDP Echo Requests to the broadcast address of the router's LAN port
step 2. Verify that that the router's LAN IP Address does not respond to the broadcast Echo Request
step 3. Send UDP Echo Requests to the broadcast address of the router's WAN port
step 4. Verify that that the router's WAN IP Address does not respond to the broadcast Echo Request
step 4. Repeat steps 1 thorugh 4 for the Daytime, QOTD, and Chargen protocols.
step 5. After recovery time, verify connectivity from LAN to WAN is still working
by running test case cdrouter_nat_1 and cdrouter_nat_2
NOTE: A Fraggle attack involves sending a large number of UDP Echo Requests to
broadcast addresses from a spoofed source address. The spoofed source address
is the address of the intended attack target. This attack can cause the target
to be flooded with UDP Echo replies creating a denial of service situation.
Smurf attacks can be suppressed by configuring devices not to respond to broadcast
pings, and configuring routers on a network not to forward packets to broadcast
addresses.
| Test |
Module |
Name |
Synopsis |
SYN floods an open port on the DUT from spoofed LAN clients |
dos.tcl |
cdrouter_dos_30 |
SYN floods an open port on the DUT from spoofed LAN clients |
Step 1. Send ARP information onto the LAN in anticipation of the DUT
needing the L2 address of a spoofed lan client
Step 2. Open a TCP connection from the same spoofed lan client with
a random source port by sending a SYN packet
Step 3. Ignore any SYN-ACK packets from the DUT
Step 4. Repeat until a configured number of iterations have completed
Step 5. After waiting for the DUT to recover, verify Internet connectivity
is still working for the real lanClient
NOTE: The amount of recovery time after the LAND attack can be configured
using the testvar 'dosRecoveryTime'. The default recovery time is 5 seconds.
The number of attack attempts can also be configured, which defaults to 100.
To configure the port being attacked, set the testvar 'dosSynAttackPort'.
Example:
testvar dosRecoveryTime 5
testvar dosSynAttackAttempts 100
testvar dosSynAttackPort 80
| Test |
Module |
Name |
Synopsis |
SYN floods an open port on the WAN from spoofed Internet addresses |
dos.tcl |
cdrouter_dos_31 |
SYN floods an open port on the WAN from spoofed Internet addresses |
Step 1. Open a TCP connection from a spoofed Internet address with
a random source port by sending a SYN packet
Step 2. Ignore any SYN-ACK packets from the DUT
Step 3. Repeat until a configured number of iterations have completed
Step 4. After waiting for the DUT to recover, verify Internet connectivity
is still working for the lanClient
NOTE: The amount of recovery time after the LAND attack can be configured
using the testvar 'dosRecoveryTime'. The default recovery time is 5 seconds.
The number of attack attempts can also be configured, which defaults to 100.
To configure the port being attacked, set the testvar 'dosSynAttackPort'.
Example:
testvar dosRecoveryTime 5
testvar dosSynAttackAttempts 100
testvar dosSynAttackPort 80
| Test |
Module |
Name |
Synopsis |
ARP floods the DUT's LAN interface |
dos.tcl |
cdrouter_dos_32 |
ARP floods the DUT’s LAN interface |
step 1. Send a gratuitous ARP Request from a spoofed IP and spoofed MAC address
step 2. Reply to the gratuitous ARP Request with a gratuitous ARP Reply to the brodcast address
step 3. Send an additional ARP Reply directly to the DUT
step 4. Repeat steps 1 through 3 until a programed number of iterations have completed
step 5. Wait for the DUT to recover, and then verify connectivity to the Internet is preserved
NOTE: The amount of recovery time after the ARP Flood attack can be configured
using the testvar 'dosRecoveryTime'. The default recovery time is 5 seconds.
The number of attack attempts can also be configured, which defaults to 100.
Example:
testvar dosRecoveryTime 5
testvar dosAttackAttempts 100
| Test |
Module |
Name |
Synopsis |
Christmas Tree floods the service ports on the WAN from spoofed Internet addresses |
dos.tcl |
cdrouter_dos_33 |
Christmas Tree floods the service ports on the WAN from spoofed Internet addresses |
Step 1. Send an invalid TCP packet from a spoofed Internet address with
a random source port by sending a Christmas packet (XMas Attack)
to a random service port on the WAN IP Address of the DUT
Step 2. Ignore any packets from the DUT
Step 3. Repeat until a configured number of iterations have completed
Step 4. After waiting for the DUT to recover, verify Internet connectivity
is still working for the lanClient
NOTE: The amount of recovery time after the Christmas Tree Attack can be configured
using the testvar 'dosRecoveryTime'. The default recovery time is 5 seconds.
The number of attack attempts can also be configured, which defaults to 100.
Example:
testvar dosRecoveryTime 5
testvar dosSynAttackAttempts 100
| Test |
Module |
Name |
Synopsis |
Floods the WAN interface with anomalous TCP packets |
dos.tcl |
cdrouter_dos_34 |
Floods the WAN interface with anomalous TCP packets |
Step 1. Send an invalid TCP packet from a spoofed Internet address with
a random source port to a random service port on the DUT's WAN IP Address
Step 2. Ignore any packets from the DUT
Step 3. Repeat until a configured number of iterations have completed
Step 4. After waiting for the DUT to recover, verify Internet connectivity
is still working for the lanClient
NOTE: The amount of recovery time after the Anomalous TCP Attack can be configured
using the testvar 'dosRecoveryTime'. The default recovery time is 5 seconds.
The number of attack attempts can also be configured, which defaults to 100.
Example:
testvar dosRecoveryTime 5
testvar dosAttackAttempts 100
xbox.tcl
Xbox LIVE compatibilty tests to simulate Xbox LIVE console tests
| Test |
Module |
Name |
Synopsis |
IP Address Test: Verify DHCP IPv4 address or static IPv4 address |
xbox.tcl |
xbox_1 |
IP Address Test: Verify DHCP IPv4 address or static IPv4 address |
step 1. Restart the DHCP client if running DHCP on the LAN
step 2. Verify DHCP client receives the same IP address and lease time
step 3. Verify DHCP lease time is greater or equal to 5 minutes
step 4. Verify LAN client can ARP for default gateway address
| Test |
Module |
Name |
Synopsis |
DNS Test: Verify DNS lookups from LAN client |
xbox.tcl |
xbox_2 |
DNS Test: Verify DNS lookups from LAN client |
step 1. Configure the primary and secondary DNS servers with the domain XEAS.XBOXLIVE.COM
step 2. Initiate a DNS lookup on the LAN client with the learned or configured DNS server
step 3. Verify the LAN client can resolve XEAS.XBOXLIVE.COM using DNS
step 4. Repeat steps 1 through 3 using the domain XETGS.XBOXLIVE.COM
step 5. Repeat steps 1 through 3 using the domain XEXDS.XBOXLIVE.COM
step 6. Repeat steps 1 through 3 using the domain notice.xbox.com
| Test |
Module |
Name |
Synopsis |
MTU Test: Verify IPv4 MTU of 1364 for Xbox LIVE |
xbox.tcl |
xbox_3 |
MTU Test: Verify IPv4 MTU of 1364 for Xbox LIVE |
step 1. Send a UDP packet from LAN to WAN using IP MTU size of 1364 and
source port 1258
step 2. UDP server on WAN should echo packet back to LAN client
step 3. Verify UDP echo succeeds with MTU of 1364
step 4. Fragmentation of UDP will cause the UDP echo to fail
step 5. Repeat steps 1 through 4 for UDP source port 1259
The max IP MTU size used by CDRouter can be configured using the testvar
'xboxMtu'. By default CDRouter uses a max IP MTU size of 1364.
The destination port used by CDRouter can be configured using the testvar
'xboxPort'. By default CDRouter uses a destination port of 3074.
| Test |
Module |
Name |
Synopsis |
ICMP Test: Verify ICMP Destination Unreachable message from WAN does not destroy NAT mapping |
xbox.tcl |
xbox_4 |
ICMP Test: Verify ICMP Destination Unreachable message from WAN does not destroy NAT mapping |
step 1. Send UDP packet with IP MTU size of 228 from LAN to WAN using
source port 1259
step 2. Verify UDP packet is received on the WAN and return an ICMP Destination Unreachable message
step 3. Verify ICMP Destination Unreachable message is received on the LAN
step 4. Send UDP response from WAN to LAN
step 5. Verify UDP response is received on LAN since NAPT mapping is still working
Refrence:
Xbox Compatibility Testing http://www.qacafe.com/notes/show/8
| Test |
Module |
Name |
Synopsis |
NAT Test: Verify Xbox NAT classification of Open, Moderate, or Strict |
xbox.tcl |
xbox_5 |
NAT Test: Verify Xbox NAT classification of Open, Moderate, or Strict |
PART A: Verify if UPnP is enabled:
step 1. Send UPnP M-SEARCH for WANIPConnection and WANPPPConnection services
step 2. If found, initiate a UPnP GetStatusInfo Action on either service
step 3. Consider UPnP enabled if Action succeeds
PART B: Verify the shape of NAT to either symmetric or cone:
step 1. Initiate UDP packet from LAN to WAN server
step 2. Initiate UDP packet using same src port to different WAN server
step 3. If WAN side src port changes, the device is using symmetric NAT
PART C: Verify the type of NAT filtering:
step 1. Initiate UDP packet from LAN to WAN server
step 2. Forward return packet from WAN using different WAN src address
step 3. If packet is forwarded to the LAN, full-cone NAT is in use
step 4. Forward packet from original WAN server using differnt src address
step 5. If packet is forwarded to the LAN, address-restricted NAT is in use
step 6. Otherwise, NAT implementation is considered to be port-restricted
PART D: Rate the type of NAT:
Step 1. If UPnP is enabled, the NAT type is open
Step 2. If device is using full-clone NAT, the NAT type is open
Step 3. If device is using address-restricted or port-restricted NAT, the NAT type is moderate
Step 4. If device is using symmetric NAT, the NAT type is strict
Step 5. Test passes if NAT type matches minimal NAT type or is more open.
NOTE: You can configure the minimal NAT type using the testvar xboxNatMinType. The
default minimum NAT type is open. The xboxNatMinType values are
open, moderate, and strict.
testvar xboxNatMinType open
Refrence:
Xbox Compatibility Testing http://www.qacafe.com/notes/show/8
| Test |
Module |
Name |
Synopsis |
UPnP Test: Verify UDP wildcard port mapping can be created |
xbox.tcl |
xbox_6 |
UPnP Test: Verify UDP wildcard port mapping can be created |
step 1. Find Control URL for WANIPConnection or WANPPPConnection service
step 2. Send UPnP Action for AddPortMapping with wildcard for
NewRemoteHost (""), NewExternalPort 3074, NewProtocol UDP,
NewInternalPort 3074, and NewLeaseDuration of 0
step 3. Verify Action returns HTTP 200 status code
step 4. Initiate inbound UDP connection using new port mapping
step 5. Verify UDP connection is established
step 6. Initiate outbound UDP connection using new port mapping
step 7. Verify UDP connection is established
step 8. Delete port mapping using DeletePortMapping Action
step 9. Wait 5 seconds for port mapping to be deleted
step 10. Initiate inbound UDP connection for port mapping from WAN side
step 11. Verify inbound UDP connection is blocked
The source and destination port used by CDRouter for the port mapping can be
configured using the testvar 'xboxPort'. By default CDRouter uses a source
and destination port of 3074.
The testvar 'upnpWANPPPConnection' is used to configure the test case
to use the WANPPPConnection service. By default CDrouter uses the
WANIPConnection service.
sctp.tcl
SCTP related test cases
| Test |
Module |
Name |
Synopsis |
Verify SCTP association initiation and termination |
sctp.tcl |
sctp_1 |
Verify SCTP association initiation and termination |
step 1. Initiate SCTP association from LAN client to WAN server
step 2. Verify association initiation is successful
step 3. Terminate SCTP association from LAN side
step 4. Verify association is terminated successful
References:
IETF RFC 4960 "Stream Control Transmission Protocol"
https://tools.ietf.org/html/rfc4960
| Test |
Module |
Name |
Synopsis |
Verify SCTP association with bidirectional data transfer |
sctp.tcl |
sctp_2 |
Verify SCTP association with bidirectional data transfer |
step 1. Initiate an outbound SCTP association from LAN client to WAN
server
step 2. Verify association initiation is successful
step 3. Transmit SCTP data from LAN client to WAN server
step 4. Verify WAN server receives SCTP data
step 5. Transmit SCTP data from WAN server to LAN client
step 6. Verify LAN client receives SCTP data
step 7. Terminate SCTP association from LAN side
step 8. Verify association is terminated successful
References:
IETF RFC 4960 "Stream Control Transmission Protocol"
https://tools.ietf.org/html/rfc4960
| Test |
Module |
Name |
Synopsis |
Verify two simulataneous SCTP associations to same WAN server |
sctp.tcl |
sctp_3 |
Verify two simulataneous SCTP associations to same WAN server |
step 1. Initiate an outbound SCTP association from LAN client to WAN
server
step 2. Initiate an outbound SCTP association from second LAN client
to the same WAN server
step 3. Verify association initiation from step 1 is successful
step 4. Verify association initiation from step 2 is successful
step 5. Terminate SCTP association from first LAN client
step 6. Terminate SCTP association from second LAN client
step 7. Verify first LAN client's association is terminated successfully
step 8. Verify second LAN client's association is terminated successfully
References:
IETF RFC 4960 "Stream Control Transmission Protocol"
https://tools.ietf.org/html/rfc4960
| Test |
Module |
Name |
Synopsis |
Verify two simulataneous SCTP associations with same source port to same WAN server |
sctp.tcl |
sctp_4 |
Verify two simulataneous SCTP associations with same source port to same WAN server |
step 1. Initiate an outbound SCTP association from LAN client to WAN
server
step 2. Initiate an outbound SCTP association from second LAN
client using same source port as the first LAN client to the
same WAN server
step 3. Verify association initiation from step 1 is successful
step 4. Verify association initiation from step 2 is successful
step 5. Terminate SCTP association from first LAN client
step 6. Terminate SCTP association from second LAN client
step 7. Verify first LAN client's association is terminated successfully
step 8. Verify second LAN client's association is terminated successfully
References:
IETF RFC 4960 "Stream Control Transmission Protocol"
https://tools.ietf.org/html/rfc4960
lldp.tcl
LLDP tests
| Test |
Module |
Name |
Synopsis |
Verify LLDP message transmission interval |
lldp.tcl |
lldp_1 |
Verify LLDP message transmission interval |
step 1. Wait up to lldpMsgTxInterval seconds for DUT to transmit
an LLDP packet on LAN side
step 2. Verify the DUT transmits the packet after
lldpMsgTxInterval seconds
step 3. Repeat steps 1 through 2 three times
Note: The test is skipped unless supportsLLDP is yes. Also, this
test will only listen for LLDP packets from the MAC address
lldpLanMac.
| Test |
Module |
Name |
Synopsis |
Verify LLDP new neighbor detection |
lldp.tcl |
lldp_2 |
Verify LLDP new neighbor detection |
step 1. Start new DHCP client on LAN interface
step 2. Transmit an LLDP packet from new DHCP client
step 3. Verify the DUT detects a new LLDP neighbor and quickly
transmits lldpTxFastInit LLDP packets on the LAN side
Note: The test is skipped unless supportsLLDP is yes. Also, this
test will only listen for LLDP packets from the MAC address
lldpLanMac.
| Test |
Module |
Name |
Synopsis |
Verify Chassis TLV in DUT's LLDP message |
lldp.tcl |
lldp_3 |
Verify Chassis TLV in DUT’s LLDP message |
step 1. Wait up to lldpMsgTxInterval seconds for DUT to transmit
an LLDP packet on LAN side
step 2. Verify MAC address in MAC address Chassis TLV matches
source MAC of the DUT's LAN interface
Note: The test is skipped unless supportsLLDP is yes. Also, this
test will only listen for LLDP packets from the MAC address
lldpLanMac. If the MAC address in the DUT's Chassis TLV is not
the same as lldpLanMac, configure the testvar lldpLanChassisMac.
| Test |
Module |
Name |
Synopsis |
Verify System Name TLV in DUT's LLDP message |
lldp.tcl |
lldp_4 |
Verify System Name TLV in DUT’s LLDP message |
step 1. Wait up to lldpMsgTxInterval seconds for DUT to transmit
an LLDP packet on LAN side
step 2. Verify value of System Name TLV matches DUT's expected LAN
hostname.
Note: The DUT's expected LAN hostname is configured using the
testvar lanHostname.
Note: The test is skipped unless supportsLLDP is yes. Also, this
test will only listen for LLDP packets from the MAC address
lldpLanMac.
rfc5508.tcl
IETF RFC 5508 NAT behavioral requirements for ICMP
| Test |
Module |
Name |
Synopsis |
Section 3.1: ICMP Query Mapping, REQ-1 |
rfc5508.tcl |
rfc5508_req_1 |
Section 3.1: ICMP Query Mapping, REQ-1 |
step 1. Send ICMP Echo Request from LAN client to WAN host A with
ICMP ID X
step 2. Verify ICMP Echo Request reaches WAN host A with
translated ICMP ID X'
step 3. Send a second ICMP Echo Request from LAN client to WAN
host A with ID X
step 4. Verify ICMP Echo Request reaches WAN host A, verify ICMP
ID X' is unchanged
step 5. Send ICMP Echo Request from LAN client to WAN host B with
ICMP ID X
step 6. Verify ICMP Echo Request reaches WAN host B, verify ICMP
ID X' is unchanged
References:
IETF RFC 5508 "NAT Behavioral Requirements for TCP" Section 3.1: ICMP Query Mapping
REQ-1: Unless explicitly overridden by local policy, a NAT device
MUST permit ICMP Queries and their associated responses, when
the Query is initiated from a private host to the external
hosts.
a. NAT mapping of ICMP Query Identifiers SHOULD be external-
host independent.
https://tools.ietf.org/html/rfc5508#section-3.1
| Test |
Module |
Name |
Synopsis |
Section 3.2: ICMP Query Session Timeouts, REQ-2 |
rfc5508.tcl |
rfc5508_req_2 |
Section 3.2: ICMP Query Session Timeouts, REQ-2 |
step 1. Configure WAN host A to not respond to ICMP Echo Requests
step 2. Send ICMP Echo Request from LAN client to WAN host A
step 3. Wait slightly less than 60 seconds
step 4. Send ICMP Echo Reply back from WAN host A to LAN client
step 5. Verify LAN client receives ICMP Echo Reply from WAN host A
References:
IETF RFC 5508 "NAT Behavioral Requirements for TCP" Section 3.2: ICMP Query Session Timeouts
Setting the ICMP NAT session timeout to a very large duration
(say, 240 seconds) could potentially tie up precious NAT resources
such as Query mappings and NAT Sessions for the whole duration.
On the other hand, setting the timeout very low can result in
premature freeing of NAT resources and applications failing to
complete gracefully. The ICMP Query session timeout needs to be a
balance between the two extremes. A 60-second timeout is a
balance between the two extremes. An ICMP Query session timer
MUST NOT expire in less than 60 seconds. It is RECOMMENDED that
the ICMP Query session timer be made configurable.
REQ-2: An ICMP Query session timer MUST NOT expire in less than 60
seconds.
a. It is RECOMMENDED that the ICMP Query session timer be made
configurable.
https://tools.ietf.org/html/rfc5508#section-3.2
| Test |
Module |
Name |
Synopsis |
Section 4.1: ICMP Error Payload Validation, REQ-3 |
rfc5508.tcl |
rfc5508_req_3 |
Section 4.1: ICMP Error Payload Validation, REQ-3 |
step 1. Send ICMP Echo Request from LAN client to WAN host
step 2. Send ICMP Port Unreachable with bad checksum from WAN host to LAN client
step 3. Verify ICMP Port Unreachable is not forwarded to LAN client
References:
IETF RFC 5508 "NAT Behavioral Requirements for TCP" Section 4.1: ICMP Error Payload Validation
REQ-3: When an ICMP Error packet is received, if the ICMP checksum
fails to validate, the NAT SHOULD silently drop the ICMP Error
packet.
https://tools.ietf.org/html/rfc5508#section-4.1
| Test |
Module |
Name |
Synopsis |
Section 4.1: ICMP Error Payload Validation, REQ-3, Part A |
rfc5508.tcl |
rfc5508_req_3a |
Section 4.1: ICMP Error Payload Validation, REQ-3, Part A |
step 1. Send ICMP Echo Request from LAN client to WAN host
step 2. Send ICMP Port Unreachable whose inner IPv4 header
contains a bad checksum from WAN host to LAN client
step 3. Verify ICMP Port Unreachable is not forwarded to LAN client
References:
IETF RFC 5508 "NAT Behavioral Requirements for TCP" Section 4.1: ICMP Error Payload Validation
REQ-3: When an ICMP Error packet is received, if the ICMP checksum
fails to validate, the NAT SHOULD silently drop the ICMP Error
packet. If the ICMP checksum is valid, do the following:
a. If the IP checksum of the embedded packet fails to
validate, the NAT SHOULD silently drop the Error packet
https://tools.ietf.org/html/rfc5508#section-4.1
| Test |
Module |
Name |
Synopsis |
Section 4.1: ICMP Error Packet Received from the External Realm, REQ-4 |
rfc5508.tcl |
rfc5508_req_4 |
Section 4.1: ICMP Error Packet Received from the External Realm, REQ-4 |
step 1. Send stray ICMP Port Unreachable from WAN host to LAN client
step 2. Verify stray ICMP Port Unreachable is not forwarded to LAN client
step 3. Run test cdrouter_icmp_12
step 4. Run test cdrouter_icmp_13
References:
IETF RFC 5508 "NAT Behavioral Requirements for TCP" Section 4.2.1: ICMP Error Packet Received from the External Realm
REQ-4: If a NAT device receives an ICMP Error packet from an external
realm, and the NAT device does not have an active mapping for
the embedded payload, the NAT SHOULD silently drop the ICMP
Error packet. If the NAT has active mapping for the embedded
payload, then the NAT MUST do the following prior to
forwarding the packet, unless explicitly overridden by local
policy:
a. Revert the IP and transport headers of the embedded IP
packet to their original form, using the matching mapping;
and
b. Leave the ICMP Error type and code unchanged; and
c. Modify the destination IP address of the outer IP header to
be same as the source IP address of the embedded packet
after translation.
https://tools.ietf.org/html/rfc5508#section-4.2.1
| Test |
Module |
Name |
Synopsis |
Section 4.2.2: ICMP Error Packet Received from the Private Realm, REQ-5 |
rfc5508.tcl |
rfc5508_req_5 |
Section 4.2.2: ICMP Error Packet Received from the Private Realm, REQ-5 |
step 1. Send stray ICMP Port Unreachable from LAN client to WAN host
step 2. Verify stray ICMP Port Unreachable is not forwarded to WAN host
step 3. Run test cdrouter_icmp_14
References:
IETF RFC 5508 "NAT Behavioral Requirements for TCP" Section 4.2.2: ICMP Error Packet Received from the Private Realm
REQ-5: If a NAT device receives an ICMP Error packet from the private
realm, and the NAT does not have an active mapping for the
embedded payload, the NAT SHOULD silently drop the ICMP Error
packet. If the NAT has an active mapping for the embedded
payload, then the NAT MUST do the following prior to
forwarding the packet, unless explicitly overridden by local
policy.
a. Revert the IP and transport headers of the embedded IP
packet to their original form, using the matching mapping;
and
b. Leave the ICMP Error type and code unchanged; and
c. If the NAT enforces Basic NAT function [NAT-TRAD], and the
NAT has active mapping for the IP address that sent the
ICMP Error, translate the source IP address of the ICMP
Error packet with the public IP address in the mapping. In
all other cases, translate the source IP address of the
ICMP Error packet with its own public IP address.
https://tools.ietf.org/html/rfc5508#section-4.2.2
| Test |
Module |
Name |
Synopsis |
Section 4.3: NAT Sessions Pertaining to ICMP Error Payload, REQ-6 |
rfc5508.tcl |
rfc5508_req_6 |
Section 4.3: NAT Sessions Pertaining to ICMP Error Payload, REQ-6 |
step 1. Run test cdrouter_nat_360
step 2. Run test cdrouter_nat_361
References:
IETF RFC 5508 "NAT Behavioral Requirements for TCP" Section 4.3: NAT Sessions Pertaining to ICMP Error Payload
While processing an ICMP Error packet pertaining to an ICMP Query or
Query response message, a NAT device MUST NOT refresh or delete the
NAT Session that pertains to the embedded payload within the ICMP
Error packet. This is in spite of the fact that the NAT device uses
the NAT Session to translate the embedded payload. This ensures that
the NAT Session will not be modified if someone is able to spoof ICMP
Error messages for the session. [ICMP-ATK] lists a number of
potential ICMP attacks that may be attempted by malicious users on
the network. This requirement is necessary for current applications
to work correctly.
REQ-6: While processing an ICMP Error packet pertaining to an ICMP
Query or Query response message, a NAT device MUST NOT refresh
or delete the NAT Session that pertains to the embedded
payload within the ICMP Error packet.
https://tools.ietf.org/html/rfc5508#section-4.3
| Test |
Module |
Name |
Synopsis |
Section 5: Hairpinning Support for ICMP Packets, REQ-7 |
rfc5508.tcl |
rfc5508_req_7 |
Section 5: Hairpinning Support for ICMP Packets, REQ-7 |
step 1. Initiate an outbound UDP connection to server 1 from LAN source port A
step 2. Initiate a second outbound UDP connection to server 1 from LAN source port B
step 3. Detect public IP and source port for both UDP connections
step 4. Send UDP from LAN source port A to public IP and source port for connection 2
step 5. Send UDP from LAN source port B to public IP and source port for connection 1
step 6. Send UDP from LAN source port A to public IP and source port for connection 2
** NOTE: This step is required for Restricted and Port Restricted
Cone NATs. These types of NATs require an existing outgoing session
before allowing incoming packets. The test will pass packets in both
directions before trying to verify the hairpin behavior.
step 7. Verify packet is received at LAN source port B
step 8. Verify source IPv4 address and UDP port are translated to public IPv4 and port
** NOTE: The test only issues a warning if the UDP source port is not preserved.
step 9. Send UDP from LAN source port B to public IP and source port for connection 1
** NOTE: The source port is taken from the incoming UDP packet to work with
implementations that do not preserve the UDP source port.
step 10. Verify packet is received at LAN source port A
step 11. Verify source IPv4 address and UDP port are translated to public IPv4 and port
step 12. Send an ICMP Destination Unreachable message with an
embedded IP packet matching the hairpin NAT binding from
LAN.
step 13. Verify that the ICMP Destination Unreachable message is
forwarded and that the destination IP address of the
outer IP header matches the source IP address of the
embedded IP packet.
NOTES: This test scenario should work for all Cone NAT implementations - Full
Cone NAT, Restricted Cone NAT, and Port Restricted Cone NAT. For a discussion
of each type of Cone NAT, please see RFC 3489.
This test is only run when the testvar 'natSupportsP2P' is set to yes.
References:
IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 6: Hairpinning Behavior
https://tools.ietf.org/html/rfc4787#section-6
IETF RFC 5508 "NAT Behavioral Requirements for TCP" Section 5: Hairpinning Support for ICMP Packets
REQ-7: NAT devices enforcing Basic NAT [NAT-TRAD] MUST support the
traversal of hairpinned ICMP Query sessions. All NAT devices
(i.e., Basic NAT as well as NAPT devices) MUST support the
traversal of hairpinned ICMP Error messages:
a. When forwarding a hairpinned ICMP Error message, the NAT
device MUST translate the destination IP address of the
outer IP header to be same as the source IP address of the
embedded IP packet after the translation.
https://tools.ietf.org/html/rfc5508#section-5
rfc4787.tcl
RFC 4787 NAT behavioral requirements for unicast UDP
| Test |
Module |
Name |
Synopsis |
Section 4.1: Address and Port Mapping, REQ-1 Mapping Behavior |
rfc4787.tcl |
rfc4787_req_1 |
Section 4.1: Address and Port Mapping, REQ-1 Mapping Behavior |
step 1. Transmit a UDP packet from LAN client with source port X
to WAN server A.
step 2. Transmit a UDP packet from LAN client with source port X
to WAN server B.
step 3. Verify WAN server B received the LAN client UDP packet
from the same source IP and source port as WAN server A.
References:
IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 4.1: Address and Port Mapping
REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior.
https://tools.ietf.org/html/rfc4787#section-4.1
| Test |
Module |
Name |
Synopsis |
Section 4.1: Address and Port Mapping, REQ-2 Address Pooling Behavior |
rfc4787.tcl |
rfc4787_req_2 |
Section 4.1: Address and Port Mapping, REQ-2 Address Pooling Behavior |
step 1. Transmit a UDP packet from LAN client with source port A
to WAN server.
step 2. Transmit a second UDP packet from LAN client with source
port B to WAN server.
step 3. Verify the WAN server received the UDP packet from step 2
from the same source IP as the UDP packet from step 1.
References:
IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 4.1: Address and Port Mapping
REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling"
behavior of "Paired". Note that this requirement is not
applicable to NATs that do not support IP address pooling.
https://tools.ietf.org/html/rfc4787#section-4.1
| Test |
Module |
Name |
Synopsis |
Section 4.2.1: Port Assignment Behavior, REQ-3 |
rfc4787.tcl |
rfc4787_req_3 |
Section 4.2.1: Port Assignment Behavior, REQ-3 |
step 1. Transmit a UDP packet from LAN client A with source port X
to WAN server on port X.
step 2. Transmit a UDP packet from LAN client B with source port X
to WAN server on port X.
step 3. Verify the WAN server received the UDP packet from step 2
from a different source port than the UDP packet from step 1.
References:
IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 4.2.1: Port Assignment Behavior
REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port
overloading".
https://tools.ietf.org/html/rfc4787#section-4.2.1
| Test |
Module |
Name |
Synopsis |
Section 4.2.2: Port Parity, REQ-4 |
rfc4787.tcl |
rfc4787_req_4 |
Section 4.2.2: Port Parity, REQ-4 |
step 1. Transmit a UDP packet from the LAN Client with a even
source port number to the WAN Server.
step 2. Verify the UDP packet received by the WAN Server has
an even source port.
step 3. Transmit a UDP packet from the LAN Client with an odd
source port number to the WAN Server.
step 4. Verify the UDP packet received by the WAN Server has
an odd source port.
step 5. Repeat steps 1 through 4 several times.
NOTE: If port parity is not supported, this test can be skipped by
configuring the testvar 'natPortParity' to 'no'.
References:
IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 4.2.2: Port Parity
REQ-4: It is RECOMMENDED that a NAT have a "Port parity
preservation" behavior of "Yes".
https://tools.ietf.org/html/rfc4787#section-4.2.2
| Test |
Module |
Name |
Synopsis |
Section 4.3: Mapping Refresh, REQ-5 Expiration Window |
rfc4787.tcl |
rfc4787_req_5 |
Section 4.3: Mapping Refresh, REQ-5 Expiration Window |
step 1. Initiate LAN client UDP ping to WAN server
step 2. Verify LAN client receives response
step 3. Wait 115 seconds
step 4. Initiate WAN client UDP ping on same connection as step 1
from WAN side
step 5. Verify WAN client receives a response
References:
IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 4.3: Mapping Refresh
REQ-5: A NAT UDP mapping timer MUST NOT expire in less than two
minutes, unless REQ-5a applies.
(a) For specific destination ports in the well-known port range
(ports 0-1023), a NAT MAY have shorter UDP mapping timers that
are specific to the IANA-registered application running over
that specific destination port.
(b) The value of the NAT UDP mapping timer MAY be configurable.
(c) A default value of five minutes or more for the NAT UDP mapping
timer is RECOMMENDED.
https://tools.ietf.org/html/rfc4787#section-4.3
| Test |
Module |
Name |
Synopsis |
Section 4.3: Mapping Refresh, REQ-6 Refresh Behavior |
rfc4787.tcl |
rfc4787_req_6 |
Section 4.3: Mapping Refresh, REQ-6 Refresh Behavior |
step 1. Transmit a UDP packet from LAN client to WAN server.
step 2. Wait natUdpTimeout - 10 seconds.
step 3. Transmit a UDP packet from LAN client to WAN server on the
same UDP connection as step 1 so that the NAT mapping is refreshed.
step 4. Wait 10 seconds.
step 5. Transmit a UDP packet from WAN server to LAN client on
same UDP connection.
step 6. Verify LAN client receives UDP packet from step 5.
step 7. Transmit a UDP packet from LAN client to WAN server.
step 8. Wait natUdpTimeout - 10 seconds.
step 9. Transmit a UDP packet from WAN server to LAN client on the
same UDP connection as step 7 so that the NAT mapping is refreshed.
step 10. Wait 10 seconds.
step 11. Transmit a UDP packet from WAN server to LAN client on
same UDP connection as step 1.
step 12. Verify LAN client receives UDP packet from step 11.
NOTE: Steps 7 - 12 will be skipped if testvar natRefreshBehavior is
not 'both'.
References:
IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 4.3: Mapping Refresh
REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound
refresh behavior" of "True".
(a) The NAT mapping Refresh Direction MAY have a "NAT Inbound
refresh behavior" of "True".
https://tools.ietf.org/html/rfc4787#section-4.3
| Test |
Module |
Name |
Synopsis |
Section 5: Filtering Behavior, REQ-8 |
rfc4787.tcl |
rfc4787_req_8 |
Section 5: Filtering Behavior, REQ-8 |
step 1. Forward a UDP packet from a LAN client to the WAN
step 2. Forward a packet back from the WAN to the same LAN client
step 3. Verify packet is received
For Full-Cone NAT
step 4. Forward a packet using a different source port but same IP address from the WAN
step 5. Verify the packet is forwarded to the LAN
step 6. Forward a packet using a different IPv4 address and same source port
step 7. Verify the packet is forwarded to the LAN
step 8. Forward a packet using the same IPv4 address and same source port
step 9. Verify the packet is forwarded to the LAN
For Address-Restricted NAT
step 4. Forward a packet using a different IPv4 address and same source port
step 5. Verify the packet is not forwarded to the LAN
step 6. Forward a packet using a different source port but same IP address from the WAN
step 7. Verify the packet is forwarded to the LAN
step 8. Forward a packet using the same IPv4 address and same source port
step 9. Verify the packet is forwarded to the LAN
For Port-Restricted NAT
step 4. Forward a packet using a different source port but same IP address from the WAN
step 5. Verify the packet is not forwarded to the LAN
step 6. Forward a packet using the same source port and IP address from the WAN
step 7. Verify the packet is forwarded to the LAN
References:
IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 5: Filtering Behavior
REQ-8: If application transparency is most important, it is
RECOMMENDED that a NAT have an "Endpoint-Independent Filtering"
behavior. If a more stringent filtering behavior is most
important, it is RECOMMENDED that a NAT have an "Address-Dependent
Filtering" behavior.
(a) The filtering behavior MAY be an option configurable by the
administrator of the NAT.
https://tools.ietf.org/html/rfc4787#section-5
| Test |
Module |
Name |
Synopsis |
Section 6: Hairpinning Behavior, REQ-9 |
rfc4787.tcl |
rfc4787_req_9 |
Section 6: Hairpinning Behavior, REQ-9 |
step 1. Initiate an outbound UDP connection to server 1 from LAN source port A
step 2. Initiate a second outbound UDP connection to server 1 from LAN source port B
step 3. Detect public IP and source port for both UDP connections
step 4. Send UDP from LAN source port A to public IP and source port for connection 2
step 5. Send UDP from LAN source port B to public IP and source port for connection 1
step 6. Send UDP from LAN source port A to public IP and source port for connection 2
** NOTE: This step is required for Restricted and Port Restricted
Cone NATs. These types of NATs require an existing outgoing session
before allowing incoming packets. The test will pass packets in both
directions before trying to verify the hairpin behavior.
step 7. Verify packet is received at LAN source port B
step 8. Verify source IPv4 address and UDP port are translated to public IPv4 and port
** NOTE: The test only issues a warning if the UDP source port is not preserved.
step 9. Send UDP from LAN source port B to public IP and source port for connection 1
** NOTE: The source port is taken from the incoming UDP packet to work with
implementations that do not preserve the UDP source port.
step 10. Verify packet is received at LAN source port A
step 11. Verify source IPv4 address and UDP port are translated to public IPv4 and port
References:
IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 6: Hairpinning Behavior
REQ-9: A NAT MUST support "Hairpinning".
(a) A NAT Hairpinning behavior MUST be "External source IP address
and port".
https://tools.ietf.org/html/rfc4787#section-6
| Test |
Module |
Name |
Synopsis |
Section 8: Deterministic Properties, REQ-11 |
rfc4787.tcl |
rfc4787_req_11 |
Section 8: Deterministic Properties, REQ-11 |
step 1. Create two additional LAN clients for a total of three
step 2. Create a second WAN server
step 3. Create UDP Servers on both WAN Servers
step 4. For each LAN client, connect to the WAN Server on port X, X+1,
and WAN Server 2 port X, using the same source port on each LAN client
step 5. Determine the NAT translation model by inspecting the NAT IP Address and Port used
for each connection.
step 6. Determine whether the NAT translation model was persistent across all three LAN clients
step 7. Shut down the UDP WAN Servers. Install UDP Servers on each LAN client,
listening to the port the LAN client originally sent a packet from.
step 8. Attempt to connect to each NAT mapping per LAN client from each of the
original WAN Server destination ports.
step 9. Determine whether the NAT filtering model was persistent across all three LAN clients
References:
IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 8: Deterministic Properties
REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT
change the NAT translation (Section 4) or the Filtering
(Section 5) Behavior at any point in time, or under any particular
conditions.
https://tools.ietf.org/html/rfc4787#section-8
| Test |
Module |
Name |
Synopsis |
Section 9: ICMP Destination Unreachable Behavior, REQ-12 |
rfc4787.tcl |
rfc4787_req_12 |
Section 9: ICMP Destination Unreachable Behavior, REQ-12 |
step 1. Send UDP packet from LAN to WAN
step 2. Verify UDP packet is received on the WAN and return an ICMP Destination Unreachable message
step 3. Verify ICMP Destination Unreachable message is received on the LAN
step 4. Send UDP response from WAN to LAN
step 5. Verify UDP response is received on LAN since NAPT mapping is still working
References:
IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 9: ICMP Destination Unreachable Behavior
REQ-12: Receipt of any sort of ICMP message MUST NOT terminate the
NAT mapping.
(a) The NAT's default configuration SHOULD NOT filter ICMP messages
based on their source IP address.
(b) It is RECOMMENDED that a NAT support ICMP Destination
Unreachable messages.
https://tools.ietf.org/html/rfc4787#section-9
| Test |
Module |
Name |
Synopsis |
Section 10: Fragmentation of Outgoing Packets, REQ-13 |
rfc4787.tcl |
rfc4787_req_13 |
Section 10: Fragmentation of Outgoing Packets, REQ-13 |
step 1. Create a packet larger than the WAN connection MTU, to force fragmentation
step 2. Set the DF field of the packet to 1
step 3. Send the packet from the LAN client to the WAN server
step 4. Verify an ICMP Type 3, Code 4 message is received by the LAN client
step 5. Recreate the packet from step 1
step 6. Set the DF field of the packet to 0
step 7. Send the packet from the LAN client to the WAN server
step 8. Verify the fragmented packet is received on the WAN server
NOTE: This behavior is appliciable under only the original framing of
Section 10, 'When the MTU of the adjacent link is too small'. This behavior
is not expected when the packet would not require fragmentation.
NOTE: This test will be skipped if the testvar 'wanMode' is not a WAN
topology with an MTU smaller than the LAN MTU (Typically 1500).
References:
IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 10: Fragmentation of Outgoing Packets
REQ-13: If the packet received on an internal IP address has DF=1,
he NAT MUST send back an ICMP message "Fragmentation needed and
DF set" to the host, as described in [RFC0792].
(a) If the packet has DF=0, the NAT MUST fragment the packet and
SHOULD send the fragments in order.
https://tools.ietf.org/html/rfc4787#section-10
| Test |
Module |
Name |
Synopsis |
Section 11: Receiving Fragmented Packets, REQ-14 |
rfc4787.tcl |
rfc4787_req_14 |
Section 11: Receiving Fragmented Packets, REQ-14 |
step 1. Send a set of UDP Echo fragment packets from the LAN client
to the WAN server in reverse order
step 2. Verify the WAN server replies to the LAN client
References:
IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 11: Receiving Fragmented Packets
REQ-14: A NAT MUST support receiving in-order and out-of-order
fragments, so it MUST have "Received Fragment Out of Order"
behavior.
(a) A NAT's out-of-order fragment processing mechanism MUST be
designed so that fragmentation-based DoS attacks do not
compromise the NAT's ability to process in-order and
unfragmented IP packets.
https://tools.ietf.org/html/rfc4787#section-11
http.tcl
HTTP related test cases
| Test |
Module |
Name |
Synopsis |
Verify HTTP/1.0 GET connections |
http.tcl |
cdrouter_http_100 |
Verify HTTP/1.0 GET connections |
step 1. Send an HTTP/1.0 GET request to server
step 2. Verify HTTP response is received
References:
IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"
https://tools.ietf.org/html/rfc1945
| Test |
Module |
Name |
Synopsis |
Verify HTTP/1.0 POST connections |
http.tcl |
cdrouter_http_101 |
Verify HTTP/1.0 POST connections |
step 1. Send an HTTP/1.0 POST request to server
step 2. Verify HTTP response is received
References:
IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"
https://tools.ietf.org/html/rfc1945
| Test |
Module |
Name |
Synopsis |
Verify HTTP/1.0 HEAD connections |
http.tcl |
cdrouter_http_102 |
Verify HTTP/1.0 HEAD connections |
step 1. Send an HTTP/1.0 HEAD request to server
step 2. Verify HTTP response is received
References:
IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"
https://tools.ietf.org/html/rfc1945
| Test |
Module |
Name |
Synopsis |
Verify HTTP/1.0 GET connections with large number of headers |
http.tcl |
cdrouter_http_103 |
Verify HTTP/1.0 GET connections with large number of headers |
step 1. Send a HTTP/1.0 GET request to the server with the maximum allowed headers
step 2. Verify the HTTP response is received
NOTE: The testvar httpMaxHeaderCount can be used to configure the number of
headers that are applied during this test.
References:
IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"
https://tools.ietf.org/html/rfc1945
| Test |
Module |
Name |
Synopsis |
Verify HTTP/1.1 GET connections |
http.tcl |
cdrouter_http_200 |
Verify HTTP/1.1 GET connections |
step 1. Send an HTTP/1.1 GET request to server
step 2. Verify HTTP response is received
References:
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify HTTP/1.1 POST connections |
http.tcl |
cdrouter_http_201 |
Verify HTTP/1.1 POST connections |
step 1. Send an HTTP/1.1 POST request to server
step 2. Verify HTTP response is received
References:
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify HTTP/1.1 HEAD connections |
http.tcl |
cdrouter_http_202 |
Verify HTTP/1.1 HEAD connections |
step 1. Send an HTTP/1.1 HEAD request to server
step 2. Verify HTTP response is received
References:
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify HTTP/1.1 PUT connections |
http.tcl |
cdrouter_http_203 |
Verify HTTP/1.1 PUT connections |
step 1. Send an HTTP/1.1 PUT request to server
step 2. Verify HTTP response is received
References:
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify HTTP/1.1 OPTIONS connections |
http.tcl |
cdrouter_http_204 |
Verify HTTP/1.1 OPTIONS connections |
step 1. Send an HTTP/1.1 OPTIONS request to server
step 2. Verify HTTP response is received
References:
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify HTTP/1.1 DELETE connections |
http.tcl |
cdrouter_http_205 |
Verify HTTP/1.1 DELETE connections |
step 1. Send an HTTP/1.1 DELETE request to server
step 2. Verify HTTP response is received
References:
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify HTTP/1.1 GET connections with large number of headers |
http.tcl |
cdrouter_http_206 |
Verify HTTP/1.1 GET connections with large number of headers |
step 1. Send an HTTP/1.1 GET request to the server with the maximum allowed headers
step 2. Verify HTTP response is received
NOTE: The testvar httpMaxHeaderCount can be used to configure the number of
headers that are applied during this test.
References:
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify HTTP/1.1 GET connections with chunked encoding |
http.tcl |
cdrouter_http_250 |
Verify HTTP/1.1 GET connections with chunked encoding |
step 1. Send an HTTP/1.1 GET request to server
step 2. Verify HTTP response with chunked encoding is received
References:
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify HTTP/1.1 proxy idle timeout |
http.tcl |
cdrouter_http_260 |
Verify HTTP/1.1 proxy idle timeout |
step 1. Configure HTTP server to delay sending responses by the
time period specified by httpProxyIdleTimeout.
step 2. Send an HTTP/1.1 GET request to server
step 3. Verify HTTP response is received
References:
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
IETF RFC 6202 "Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP" Section 5.5: Timeouts
https://tools.ietf.org/html/rfc6202#section-5.5
| Test |
Module |
Name |
Synopsis |
Verify HTTP/1.1 pipelining |
http.tcl |
cdrouter_http_270 |
Verify HTTP/1.1 pipelining |
step 1. Send three pipelined HTTP/1.1 GET requests to server
step 2. Verify three HTTP responses are received
References:
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1" Section 8.1.2.2: Pipelining
https://tools.ietf.org/html/rfc2616#section-8.1.2.2
| Test |
Module |
Name |
Synopsis |
Verify HTTP/1.1 streaming using chunked encoding |
http.tcl |
cdrouter_http_280 |
Verify HTTP/1.1 streaming using chunked encoding |
step 1. Send an HTTP/1.1 GET request.
step 2. Verify headers of 200 OK response message are received.
step 3. Verify first chunk of 200 OK response body is received.
step 4. Pause for five seconds.
step 5. Repeat steps 3-4 for the second and third chunks of the
200 OK response body.
step 6. Verify a full HTTP response message was received.
References:
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
IETF RFC 6202 "Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP" Section 3.2: HTTP Streaming Issues
https://tools.ietf.org/html/rfc6202#section-3.2
| Test |
Module |
Name |
Synopsis |
Verify HTTP/1.1 WebSocket Ping message |
http.tcl |
cdrouter_http_300 |
Verify HTTP/1.1 WebSocket Ping message |
step 1. Send an HTTP/1.1 GET request for creation of a WebSocket
step 2. Verify WebSocket is created on the server
step 3. Send a WebSocket Ping opcode (0x9)
step 4. Verify server side returns WebSocket Pong opcode (0xA)
step 5. Close the WebSocket server
References:
IETF RFC 6455 "The WebSocket Protocol"
https://tools.ietf.org/html/rfc6455
| Test |
Module |
Name |
Synopsis |
Verify HTTP/1.1 WebSocket Text message |
http.tcl |
cdrouter_http_301 |
Verify HTTP/1.1 WebSocket Text message |
step 1. Send an HTTP/1.1 GET request for creation of a WebSocket
step 2. Verify WebSocket is created on the server
step 3. Send a WebSocket data message with text
step 4. Verify server side echos back the same text data
step 5. Close the WebSocket server
References:
IETF RFC 6455 "The WebSocket Protocol"
https://tools.ietf.org/html/rfc6455
https.tcl
HTTPS related test cases
| Test |
Module |
Name |
Synopsis |
Verify HTTPS/1.0 GET connections |
https.tcl |
cdrouter_https_100 |
Verify HTTPS/1.0 GET connections |
step 1. Send an HTTPS/1.0 GET request to server
step 2. Verify HTTPS response is received
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"
https://tools.ietf.org/html/rfc1945
| Test |
Module |
Name |
Synopsis |
Verify HTTPS/1.0 POST connections |
https.tcl |
cdrouter_https_101 |
Verify HTTPS/1.0 POST connections |
step 1. Send an HTTPS/1.0 POST request to server
step 2. Verify HTTPS response is received
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"
https://tools.ietf.org/html/rfc1945
| Test |
Module |
Name |
Synopsis |
Verify HTTPS/1.0 HEAD connections |
https.tcl |
cdrouter_https_102 |
Verify HTTPS/1.0 HEAD connections |
step 1. Send an HTTPS/1.0 HEAD request to server
step 2. Verify HTTPS response is received
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"
https://tools.ietf.org/html/rfc1945
| Test |
Module |
Name |
Synopsis |
Verify HTTPS/1.0 GET connections with large number of headers |
https.tcl |
cdrouter_https_103 |
Verify HTTPS/1.0 GET connections with large number of headers |
step 1. Send a HTTPS/1.0 GET request to the server with the maximum allowed headers
step 2. Verify the HTTPS response is received
NOTE: The testvar httpMaxHeaderCount can be used to configure the number of
headers that are applied during this test.
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"
https://tools.ietf.org/html/rfc1945
| Test |
Module |
Name |
Synopsis |
Verify HTTPS/1.1 GET connections |
https.tcl |
cdrouter_https_200 |
Verify HTTPS/1.1 GET connections |
step 1. Send an HTTPS/1.1 GET request to server
step 2. Verify HTTPS response is received
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify HTTPS/1.1 POST connections |
https.tcl |
cdrouter_https_201 |
Verify HTTPS/1.1 POST connections |
step 1. Send an HTTPS/1.1 POST request to server
step 2. Verify HTTPS response is received
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify HTTPS/1.1 HEAD connections |
https.tcl |
cdrouter_https_202 |
Verify HTTPS/1.1 HEAD connections |
step 1. Send an HTTPS/1.1 HEAD request to server
step 2. Verify HTTPS response is received
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify HTTPS/1.1 PUT connections |
https.tcl |
cdrouter_https_203 |
Verify HTTPS/1.1 PUT connections |
step 1. Send an HTTPS/1.1 PUT request to server
step 2. Verify HTTPS response is received
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify HTTPS/1.1 OPTIONS connections |
https.tcl |
cdrouter_https_204 |
Verify HTTPS/1.1 OPTIONS connections |
step 1. Send an HTTPS/1.1 OPTIONS request to server
step 2. Verify HTTPS response is received
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify HTTPS/1.1 DELETE connections |
https.tcl |
cdrouter_https_205 |
Verify HTTPS/1.1 DELETE connections |
step 1. Send an HTTPS/1.1 DELETE request to server
step 2. Verify HTTPS response is received
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify HTTPS/1.1 GET connections with large number of headers |
https.tcl |
cdrouter_https_206 |
Verify HTTPS/1.1 GET connections with large number of headers |
step 1. Send an HTTPS/1.1 GET request to the server with the maximum allowed headers
step 2. Verify HTTPS response is received
NOTE: The testvar httpMaxHeaderCount can be used to configure the number of
headers that are applied during this test.
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify HTTPS/1.1 GET connections with chunked encoding |
https.tcl |
cdrouter_https_250 |
Verify HTTPS/1.1 GET connections with chunked encoding |
step 1. Send an HTTPS/1.1 GET request to server
step 2. Verify HTTPS response with chunked encoding is received
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
https://tools.ietf.org/html/rfc2616
| Test |
Module |
Name |
Synopsis |
Verify HTTPS/1.1 WebSocket Ping message |
https.tcl |
cdrouter_https_300 |
Verify HTTPS/1.1 WebSocket Ping message |
step 1. Send an HTTPS/1.1 GET request for creation of a WebSocket
step 2. Verify WebSocket is created on the server
step 3. Send a WebSocket Ping opcode (0x9)
step 4. Verify server side returns WebSocket Pong opcode (0xA)
step 5. Close the WebSocket server
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 6455 "The WebSocket Protocol"
https://tools.ietf.org/html/rfc6455
| Test |
Module |
Name |
Synopsis |
Verify HTTPS/1.1 WebSocket Text message |
https.tcl |
cdrouter_https_301 |
Verify HTTPS/1.1 WebSocket Text message |
step 1. Send an HTTPS/1.1 GET request for creation of a WebSocket
step 2. Verify WebSocket is created on the server
step 3. Send a WebSocket data message with text
step 4. Verify server side echos back the same text data
step 5. Close the WebSocket server
References:
IETF RFC 2818 "HTTP Over TLS"
https://tools.ietf.org/html/rfc2818
IETF RFC 6455 "The WebSocket Protocol"
https://tools.ietf.org/html/rfc6455
http2.tcl
HTTP/2 related test cases
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 GET connections |
http2.tcl |
cdrouter_http2_100 |
Verify HTTP/2 GET connections |
step 1. Send an HTTP/2 GET request to server
step 2. Verify HTTP response is received
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 POST connections |
http2.tcl |
cdrouter_http2_101 |
Verify HTTP/2 POST connections |
step 1. Send an HTTP/2 POST request to server
step 2. Verify HTTP response is received
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 HEAD connections |
http2.tcl |
cdrouter_http2_102 |
Verify HTTP/2 HEAD connections |
step 1. Send an HTTP/2 HEAD request to server
step 2. Verify HTTP response is received
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 PUT connections |
http2.tcl |
cdrouter_http2_103 |
Verify HTTP/2 PUT connections |
step 1. Send an HTTP/2 PUT request to server
step 2. Verify HTTP response is received
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 OPTIONS connections |
http2.tcl |
cdrouter_http2_104 |
Verify HTTP/2 OPTIONS connections |
step 1. Send an HTTP/2 OPTIONS request to server
step 2. Verify HTTP response is received
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 DELETE connections |
http2.tcl |
cdrouter_http2_105 |
Verify HTTP/2 DELETE connections |
step 1. Send an HTTP/2 DELETE request to server
step 2. Verify HTTP response is received
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 GET connections with large number of headers |
http2.tcl |
cdrouter_http2_106 |
Verify HTTP/2 GET connections with large number of headers |
step 1. Send an HTTP/2 GET request to the server with the maximum allowed headers
step 2. Verify HTTP response is received
NOTE: The testvar httpMaxHeaderCount can be used to configure the number of
headers that are applied during this test.
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
http2-tls.tcl
HTTP/2 over TLS related test cases
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 GET connections over TLS |
http2-tls.tcl |
cdrouter_http2_tls_100 |
Verify HTTP/2 GET connections over TLS |
step 1. Send an HTTP/2 GET request to server over TLS
step 2. Verify HTTP response is received
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 POST connections over TLS |
http2-tls.tcl |
cdrouter_http2_tls_101 |
Verify HTTP/2 POST connections over TLS |
step 1. Send an HTTP/2 POST request to server over TLS
step 2. Verify HTTP response is received
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 HEAD connections over TLS |
http2-tls.tcl |
cdrouter_http2_tls_102 |
Verify HTTP/2 HEAD connections over TLS |
step 1. Send an HTTP/2 HEAD request to server over TLS
step 2. Verify HTTP response is received
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 PUT connections over TLS |
http2-tls.tcl |
cdrouter_http2_tls_103 |
Verify HTTP/2 PUT connections over TLS |
step 1. Send an HTTP/2 PUT request to server over TLS
step 2. Verify HTTP response is received
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 OPTIONS connections over TLS |
http2-tls.tcl |
cdrouter_http2_tls_104 |
Verify HTTP/2 OPTIONS connections over TLS |
step 1. Send an HTTP/2 OPTIONS request to server over TLS
step 2. Verify HTTP response is received
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 DELETE connections over TLS |
http2-tls.tcl |
cdrouter_http2_tls_105 |
Verify HTTP/2 DELETE connections over TLS |
step 1. Send an HTTP/2 DELETE request to server over TLS
step 2. Verify HTTP response is received
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
| Test |
Module |
Name |
Synopsis |
Verify HTTP/2 GET connections over TLS with large number of headers |
http2-tls.tcl |
cdrouter_http2_tls_106 |
Verify HTTP/2 GET connections over TLS with large number of headers |
step 1. Send an HTTP/2 GET request to the server over TLS with the maximum allowed headers
step 2. Verify HTTP response is received
NOTE: The testvar httpMaxHeaderCount can be used to configure the number of
headers that are applied during this test.
References:
IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"
https://tools.ietf.org/html/rfc7540
heartbleed.tcl
Heartbleed vulnerability tests for CVE-2014-0160
| Test |
Module |
Name |
Synopsis |
Verify DUT's LAN HTTPS server is protected against heartbleed exploit |
heartbleed.tcl |
cdrouter_heartbleed_100 |
Verify DUT’s LAN HTTPS server is protected against heartbleed exploit |
step 1. Open an SSL session on the DUT's LAN HTTPS server.
step 2. Transmit an SSL Heartbeat message whose length field is
larger than its payload.
step 3. Verify the DUT's LAN HTTPS server does not respond to SSL
Heartbeat message.
NOTE: The port of the DUT's LAN HTTPS server is taken from the
default secure management port defined as the first port in
the value of testvar dutSecureMgmtPort. Please read the
documentation for dutSecureMgmtPort for more information
about the default secure management port concept and its
usage.
References:
NIST CVE-2014-0160 (Heartbleed) Detail
https://nvd.nist.gov/vuln/detail/CVE-2014-0160
| Test |
Module |
Name |
Synopsis |
Verify DUT's WAN HTTPS server is protected against heartbleed exploit |
heartbleed.tcl |
cdrouter_heartbleed_200 |
Verify DUT’s WAN HTTPS server is protected against heartbleed exploit |
step 1. Open an SSL session on the DUT's WAN HTTPS server.
step 2. Transmit an SSL Heartbeat message whose length field is
larger than its payload.
step 3. Verify the DUT's WAN HTTPS server does not respond to SSL
Heartbeat message.
NOTE: The port of the DUT's WAN HTTPS server is taken from the
default secure management port defined as the first port in
the value of testvar dutSecureMgmtPort. Please read the
documentation for dutSecureMgmtPort for more information
about the default secure management port concept and its
usage.
References:
NIST CVE-2014-0160 (Heartbleed) Detail
https://nvd.nist.gov/vuln/detail/CVE-2014-0160
| Test |
Module |
Name |
Synopsis |
Verify DUT's TR-069 client is protected against heartbleed exploit |
heartbleed.tcl |
cdrouter_heartbleed_300 |
Verify DUT’s TR-069 client is protected against heartbleed exploit |
step 1. Configure the DUT to use an alternate ACS.
step 2. Initiate a new CWMP connection using Connection Request URL.
step 3. Wait for new Inform from CPE.
step 4. Transmit an SSL Heartbeat message whose length field is
larger than its payload.
step 5. Verify the DUT's WAN HTTPS server does not respond to SSL
Heartbeat message.
References:
NIST CVE-2014-0160 (Heartbleed) Detail
https://nvd.nist.gov/vuln/detail/CVE-2014-0160
ssl.tcl
SSL related test cases
| Test |
Module |
Name |
Synopsis |
Verify DUT's LAN HTTPS server refuses connections with deprecated SSL protocols |
ssl.tcl |
cdrouter_ssl_100 |
Verify DUT’s LAN HTTPS server refuses connections with deprecated SSL protocols |
step 1. Open a SSL session on the DUT's LAN HTTPS server on the
port specified by testvar dutSecureMgmtPort using a
deprecated version of SSL
step 2. Verify the SSL connection is not established
step 3. Repeat for all deprecated versions of SSL
step 4. Open a SSL sesssion using a non-deprecated version of SSL
NOTE: The list of deprecated SSL protocols is configured using the
testvar sslDeprecatedProtocols.
NOTE: The value of the DUT's LAN HTTPS port is taken from the
default secure management port defined as the first port in
the value of testvar dutSecureMgmtPort. Please read the
documentation for dutSecureMgmtPort for more information
about the default secure management port concept and its
usage.
| Test |
Module |
Name |
Synopsis |
Verify DUT's LAN HTTPS server refuses connections with deprecated SSL ciphers |
ssl.tcl |
cdrouter_ssl_200 |
Verify DUT’s LAN HTTPS server refuses connections with deprecated SSL ciphers |
step 1. Open a SSL session on the DUT's LAN HTTPS server on the
port specified by testvar dutSecureMgmtPort using a
deprecated SSL cipher
step 2. Verify the SSL connection is not established
step 3. Repeat for all deprecated SSL ciphers
step 4. Open a SSL sesssion using a non-deprecated SSL cipher
NOTE: The list of deprecated SSL ciphers is configured using the
testvar sslDeprecatedCiphers.
NOTE: The value of the DUT's LAN HTTPS port is taken from
the default secure management port defined as the first port
in the value of testvar dutSecureMgmtPort. Please read the
documentation for dutSecureMgmtPort for more information
about the default secure management port concept and its
usage.
gre.tcl
IPv4 over GRE related test cases
| Test |
Module |
Name |
Synopsis |
Verify traffic sent to remote GRE host from LAN is forwarded over IPv4 GRE tunnel |
gre.tcl |
gre_1 |
Verify traffic sent to remote GRE host from LAN is forwarded over IPv4 GRE tunnel |
step 1. Initiate outbound ICMPv4 Echo Requests from a host on the LAN to a
host within the remote GRE network on the WAN
step 2. Verify ICMPv4 Echo Replies are received
References:
IETF RFC 2784 "Generic Routing Encapsulation (GRE)"
https://tools.ietf.org/html/rfc2784
| Test |
Module |
Name |
Synopsis |
Verify traffic sent to LAN from remote GRE host is forwarded over IPv4 GRE tunnel |
gre.tcl |
gre_2 |
Verify traffic sent to LAN from remote GRE host is forwarded over IPv4 GRE tunnel |
step 1. Initiate inbound ICMPv4 Echo Requests from a host within the remote
GRE network to a host on the LAN
step 2. Verify ICMPv4 Echo Replies are received
References:
IETF RFC 2784 "Generic Routing Encapsulation (GRE)"
https://tools.ietf.org/html/rfc2784
| Test |
Module |
Name |
Synopsis |
Verify DUT's LAN IPv4 address is reachable over GRE tunnel |
gre.tcl |
gre_3 |
Verify DUT’s LAN IPv4 address is reachable over GRE tunnel |
step 1. Initiate inbound ICMPv4 Echo Requests from a host within the remote
GRE network to the DUT's LAN IPv4 address
step 2. Verify ICMPv4 Echo Reply is received
References:
IETF RFC 2784 "Generic Routing Encapsulation (GRE)"
https://tools.ietf.org/html/rfc2784
| Test |
Module |
Name |
Synopsis |
Verify GRE header fields for IPv4 packet |
gre.tcl |
gre_4 |
Verify GRE header fields for IPv4 packet |
step 1. Send an IPv4 UDP packet from a host on the LAN to a host within the
remote GRE network on the WAN
step 2. Verify that the IPv4 over GRE packet is received on the WAN
step 3. Verify the following GRE header fields within the received packet:
Checksum Present (bit 0): May be 0 or 1
Reserved0 (bits 1-12): Must be set to 0
Version Number (bits 13-15): Must be set to 0
References:
IETF RFC 2784 "Generic Routing Encapsulation (GRE)"
https://tools.ietf.org/html/rfc2784
| Test |
Module |
Name |
Synopsis |
Verify DUT forwards GRE packets with valid GRE checksums |
gre.tcl |
gre_5 |
Verify DUT forwards GRE packets with valid GRE checksums |
step 1. Enable GRE checksums for remote GRE network
step 2. Initiate outbound ICMPv4 Echo Requests from a host on the LAN to a
host within the remote GRE network on the WAN
step 3. Send ICMPv4 Echo Replies with valid GRE checksums
step 4. Verify ICMPv4 Echo Replies are received
References:
IETF RFC 2784 "Generic Routing Encapsulation (GRE)"
https://tools.ietf.org/html/rfc2784
| Test |
Module |
Name |
Synopsis |
Verify DUT drops GRE packets with bad GRE checksums |
gre.tcl |
gre_6 |
Verify DUT drops GRE packets with bad GRE checksums |
step 1. Enable GRE checksums for remote GRE network
step 2. Initiate outbound ICMPv4 Echo Requests from a host on the LAN to a
host within the remote GRE network on the WAN
step 3. Send ICMPv4 Echo Replies with bad GRE checksums
step 4. Verify ICMPv4 Echo Replies are received
References:
IETF RFC 2784 "Generic Routing Encapsulation (GRE)"
https://tools.ietf.org/html/rfc2784
| Test |
Module |
Name |
Synopsis |
Verify DUT fragments large outbound packets sent over GRE tunnel |
gre.tcl |
gre_30 |
Verify DUT fragments large outbound packets sent over GRE tunnel |
step 1. Send an IPv4 UDP packet from the LAN to a remote GRE host on the WAN
using a size that requires IPv4 fragmentation
step 2. Verify that the packet and any fragments are received on the WAN
step 3. Reassemble the packet and verify the original contents
step 4. Repeat steps 1 through 3 with IPv4 packets that range in size from
1490 bytes to 1500 bytes (these packets have a UDP payload size of
1462 to 1472 bytes)
References:
IETF RFC 2784 "Generic Routing Encapsulation (GRE)"
https://tools.ietf.org/html/rfc2784
| Test |
Module |
Name |
Synopsis |
Verify DUT sends ICMPv4 Destination Unreachables if a GRE packet needs fragmentation and DF=1 |
gre.tcl |
gre_31 |
Verify DUT sends ICMPv4 Destination Unreachables if a GRE packet needs fragmentation and DF=1 |
step 1. Send an IPv4 UDP packet from the LAN to a remote GRE host on the WAN
using a size that requires IPv4 fragmentation with DF=1
step 2. Verify that the DUT sends an ICMPv4 Destination Unreachable
step 3. Verify that the ICMP code is 4 'fragmentation needed and DF set'
References:
IETF RFC 2784 "Generic Routing Encapsulation (GRE)"
https://tools.ietf.org/html/rfc2784
IETF RFC 1191 "Path MTU Discovery" Section 2: Protocol overview
In this memo, we describe a technique for using the Don't Fragment
(DF) bit in the IP header to dynamically discover the PMTU of a path.
The basic idea is that a source host initially assumes that the PMTU
of a path is the (known) MTU of its first hop, and sends all
datagrams on that path with the DF bit set. If any of the datagrams
are too large to be forwarded without fragmentation by some router
along the path, that router will discard them and return ICMP
Destination Unreachable messages with a code meaning "fragmentation
needed and DF set" [7]. Upon receipt of such a message (henceforth
called a "Datagram Too Big" message), the source host reduces its
assumed PMTU for the path.
https://tools.ietf.org/html/rfc1191#section-2
| Test |
Module |
Name |
Synopsis |
Verify DUT reassembles and forwards fragmented IPv4 UDP packets from the LAN over GRE tunnel |
gre.tcl |
gre_32 |
Verify DUT reassembles and forwards fragmented IPv4 UDP packets from the LAN over GRE tunnel |
step 1. Send an IPv4 UDP packet from the LAN to a remote GRE host on the WAN
using a size that does not require fragmentation; send the packet as
two IPv4 fragments
step 2. Verify that the packet is reassembled and forwarded over the GRE
tunnel by the DUT and received by the GRE host on the WAN
References:
IETF RFC 2784 "Generic Routing Encapsulation (GRE)"
https://tools.ietf.org/html/rfc2784
| Test |
Module |
Name |
Synopsis |
Verify DUT reassembles and forwards fragmented IPv4 UDP packets from the WAN over GRE tunnel |
gre.tcl |
gre_34 |
Verify DUT reassembles and forwards fragmented IPv4 UDP packets from the WAN over GRE tunnel |
step 1. Send an IPv4 UDP packet from the LAN to a remote GRE host on the WAN
to establish an outbound connection
step 2. Verify that the packet is received on the WAN
step 3. Send an IPv4 UDP packet with a total UDP length of 1470 bytes from
a remote GRE host on the WAN to a host on the LAN; send the packet
as two IPv4 fragments
step 4. Verify that the packet is reassembled and forwarded over the GRE
tunnel by the DUT and received by the LAN host
step 5. Repeat steps 2 through 4 for packets with total UDP lengths from
1470 to 1480
References:
IETF RFC 2784 "Generic Routing Encapsulation (GRE)"
https://tools.ietf.org/html/rfc2784
| Test |
Module |
Name |
Synopsis |
Verify DUT reassembles and forwards fragmented IPv4 UDP packets from the WAN over GRE tunnel that also require fragmentation on the LAN |
gre.tcl |
gre_35 |
Verify DUT reassembles and forwards fragmented IPv4 UDP packets from the WAN over GRE tunnel that also require fragmentation on the LAN |
step 1. Send an IPv4 UDP packet from the LAN to a remote GRE host on the WAN
to establish an outbound connection
step 2. Verify that the packet is received on the WAN
step 3. Send an IPv4 UDP packet with a total UDP length of 7997 bytes from
a remote GRE host on the WAN to a host on the LAN; send the packet
as two IPv4 fragments
step 4. Verify that the packet is reassembled and forwarded over the GRE
tunnel by the DUT and received by the LAN host
step 5. Repeat steps 2 through 4 for packets with total UDP lengths from
7997 to 8000
References:
IETF RFC 2784 "Generic Routing Encapsulation (GRE)"
https://tools.ietf.org/html/rfc2784
| Test |
Module |
Name |
Synopsis |
Verify DUT properly reassembles and forwards out of order IPv4 fragments |
gre.tcl |
gre_36 |
Verify DUT properly reassembles and forwards out of order IPv4 fragments |
step 1. Send an IPv4 UDP Echo packet from the LAN to a remote GRE host on
the WAN
step 2. Send an IPv4 UDP Echo response packet from the remote GRE host on
the WAN to the LAN host; fragment the packet and send the fragments
in reverse order
step 3. Verify that the packet is reassembled and forwarded over the GRE
tunnel by the DUT and received by the LAN host
References:
IETF RFC 2784 "Generic Routing Encapsulation (GRE)"
https://tools.ietf.org/html/rfc2784
| Test |
Module |
Name |
Synopsis |
Verify DUT sets the DF flag in the GRE delivery header |
gre.tcl |
gre_50 |
Verify DUT sets the DF flag in the GRE delivery header |
step 1. Send an IPv4 UDP packet to a remote GRE host on the WAN with the DF
flag set to 0
step 2. Verify packet is received by remote GRE host on the WAN
step 3. Verify the DF flag in the GRE header based on the testvar greDFflag:
When payload DF=0:
"inherit" - the DF flag should be 0
"off" - the DF flag should be 0
"on" - the DF flag should be 1
When payload DF=1
"inherit" - the DF flag should be 1
"off" - the DF flag should be 0
"on" - the DF flag should be 1
step 4. Repeat steps 1 through 3 for DF flag set to 1
Referneces:
RFC 2784
RFC 7588 A Widely Deployed Solution to the Generic
Routing Encapsulation (GRE) Fragmentation Problem
3.3.2.1. Tunneling GRE over IPv4
By default, the GRE ingress node does not fragment delivery packets.
However, the GRE ingress node includes a configuration option that
allows delivery packet fragmentation.
By default, the GRE ingress node sets the DF bit in the delivery
header to 1 (Don't Fragment). However, the GRE ingress node also
supports a configuration option that invokes the following behavior:
o When the GRE payload is IPv6, the DF bit on the delivery header is
set to 0 (Fragments Allowed).
o When the GRE payload is IPv4, the DF bit is copied from the
payload header to the delivery header.
When the DF bit on an IPv4 delivery header is set to 0, the GRE
delivery packet can be fragmented by any router between the GRE
ingress and egress nodes.
References:
IETF RFC 2784 "Generic Routing Encapsulation (GRE)"
https://tools.ietf.org/html/rfc2784
| Test |
Module |
Name |
Synopsis |
Verify DUT drops invalid GRE packets |
gre.tcl |
gre_60 |
Verify DUT drops invalid GRE packets |
step 1. Initiate an outbound ICMPv4 Echo Request from a host on the LAN to a
host within the remote GRE network on the WAN
step 2. Send an invalid ICMPv4 Echo Reply packet with a shortened GRE header
step 3. Verify that the ICMPv4 Echo Reply packet is not forwarded to the LAN
step 4. Repeat
References:
IETF RFC 2784 "Generic Routing Encapsulation (GRE)"
https://tools.ietf.org/html/rfc2784
| Test |
Module |
Name |
Synopsis |
Verify DUT supports PMTU discovery for packets sent over GRE tunnel |
gre.tcl |
gre_80 |
Verify DUT supports PMTU discovery for packets sent over GRE tunnel |
step 1. Send 1500 byte UDP packet with IP Don't Fragment Flag = 1 to the
remoteVpn host over the GRE tunnel
step 2. Check for an ICMP Destination Unreachable packet with code = 4
step 3. Repeat process two more times until an ICMP Destination
Unreachable is received, or all 3 packets are sent
step 4. If an ICMP Destination Unreachable was sent, verify the
the code value is 4 and verify MTU value in the ICMP header
step 5. Reduce the UDP packet size by 1 byte and repeat the process
until no ICMP Destination Unreachable is sent
step 6. When a packet size is found that does not generate an
ICMP Destination Unreachable, verify packets can be forwarded over
GRE tunnel using this packet size
step 7. Verify the final MTU size is the same as the MTU size
reported in the ICMP Destination Unreachable packet
NOTE: Some devices rate limit the number of ICMP packets that may be sent.
This test will sent 3 UDP packets over a 15 second window in order to
generate an ICMP unreachable packet. If your device uses rate limiting on
ICMP packets, it must allow at least 1 ICMP packet every 10 seconds.
References:
IETF RFC 2784 "Generic Routing Encapsulation (GRE)"
https://tools.ietf.org/html/rfc2784
IETF RFC 1191 "Path MTU Discovery"
https://tools.ietf.org/html/rfc1191
| Test |
Module |
Name |
Synopsis |
Verify that all configured IPv4 over GRE tunnels are capable of forwarding traffic |
gre.tcl |
gre_100 |
Verify that all configured IPv4 over GRE tunnels are capable of forwarding traffic |
step 1. Initiate outbound ICMPv4 Echo Requests from a host on the LAN to a
host within the remote GRE network on the WAN
step 2. Verify ICMPv4 Echo Replies are received
step 3. Repeat steps 1 and 2 for all configured GRE tunnels
References:
IETF RFC 2784 "Generic Routing Encapsulation (GRE)"
https://tools.ietf.org/html/rfc2784
wifi.tcl
WiFi client association and verification tests
| Test |
Module |
Name |
Synopsis |
Graceful wireless LAN client restart |
wifi.tcl |
wifi_1 |
Graceful wireless LAN client restart |
step 1. Release LAN client's IPv4 address via DHCP
step 2. If IPv6 is enabled and DHCPv6 was used on the LAN, also release LAN
client's IPv6 address
step 2. Force LAN client to disassociate from DUT's AP
step 3. Force LAN client to associate to DUT's AP using initial association
parameters
step 4. Restart DHCP (and DHCPv6, if enabled) on LAN client to obtain IPv4
and IPv6 addresses
step 5. Send 10 IPv4 (and IPv6, if enabled) pings from the LAN client to a
remote host on WAN to verify connectivity
NOTE: This test simulates a graceful restart by a wireless LAN client where
the DHCP address is released before the wireless disassociation occurs.
| Test |
Module |
Name |
Synopsis |
Restart wireless LAN client without releasing address |
wifi.tcl |
wifi_2 |
Restart wireless LAN client without releasing address |
step 1. Force LAN client to disassociate from DUT's AP
step 2. Force LAN client to associate to DUT's AP using initial association
parameters
step 3. Restart DHCP (and DHCPv6, if enabled) on LAN client to obtain IPv4
and IPv6 addresses
step 4. Send 10 IPv4 (and IPv6, if enabled) pings from the LAN client to a
remote host on WAN to verify connectivity
NOTE: This test simulates a sudden restart by a wireless LAN client where
the DHCP address is not released before the wireless disassociation occurs.
| Test |
Module |
Name |
Synopsis |
Restart wireless LAN client without releasing or obtaining a new address |
wifi.tcl |
wifi_3 |
Restart wireless LAN client without releasing or obtaining a new address |
step 1. Force LAN client to disassociate from DUT's AP
step 2. Force LAN client to associate to DUT's AP using initial association
parameters
step 3. Send 10 IPv4 (and IPv6, if enabled) pings from the LAN client to a
remote host on WAN to verify connectivity
NOTE: This test simulates a sudden restart by a wireless LAN client where
the DHCP address is not released before the wireless disassociation occurs
and DHCP is not restarted when re-associated.
| Test |
Module |
Name |
Synopsis |
Verify connectivity using all wifi modes advertised by the DUT |
wifi.tcl |
wifi_10 |
Verify connectivity using all wifi modes advertised by the DUT |
step 1. Release LAN client's IPv4 address via DHCP if enabled
step 2. If IPv6 is enabled and DHCPv6 was used on the LAN, also release LAN
client's IPv6 address
step 3. Force LAN client to disassociate from DUT's AP
step 4. Force LAN client to associate to DUT's AP using an 802.11 phy mode,
WPA mode, WPA key management mode, WPA pairwise cipher, and WPA
group cipher advertised by the DUT in its wifi beacons on the LAN
step 5. Restart DHCP and/or DHCPv6, if enabled, on LAN client to obtain IPv4
and IPv6 addresses
step 6. Send 10 IPv4 (and IPv6, if enabled) pings from the LAN client to a
remote host on WAN to verify connectivity
step 7. Repeat steps 1 through 6 for all combinations of 802.11 phy mode,
WPA mode, WPA key management mode, WPA pairwise cipher, and WPA
group cipher supported by the DUT
step 8. Repeat steps 1 through 6 to re-associate LAN client with original
wireless configuration
This test cycles through all advertised, supported modes and verifies that
a client can associate to the DUT and forward traffic.
If the DUT is configured for WEP or no security, this test will cycle
through all supported 802.11 phy modes using the existing security settings.
NOTE: 802.11b and 802.11g association modes are virtually the same. If the
DUT advertises support for 802.11b, CDRouter will associate as an 802.11b/g
compatible client.
| Test |
Module |
Name |
Synopsis |
Verify DUT prevents use of TKIP cipher when using HT/VHT/HE |
wifi.tcl |
wifi_11 |
Verify DUT prevents use of TKIP cipher when using HT/VHT/HE |
step 1. Release LAN client's IPv4 address via DHCP if enabled
step 2. If IPv6 is enabled and DHCPv6 was used on the LAN, also release LAN
client's IPv6 address
step 3. Force LAN client to disassociate from DUT's AP
step 4. Force LAN client to associate to DUT's AP using a HT, VHT, or HE phy
and a pairwise cipher of TKIP
step 5. Ensure that the DUT either did not allow the LAN client to associate
or the DUT's AP forced the LAN client to associate using an 802.11a phy
step 6. Restart DHCP and/or DHCPv6, if enabled, on LAN client to obtain IPv4
and IPv6 addresses
step 7. Send 10 IPv4 (and IPv6, if enabled) pings from the LAN client to a
remote host on WAN to verify connectivity
step 8. Repeat steps 1 through 7 for all combinations of HT/VHT/HE phy mode,
WPA mode, WPA key management mode, supported by the DUT
step 9. Re-associate LAN client with original wireless configuration
This test cycles through all advertised, supported modes and verifies that
a client cannot associate to the AP using TKIP and 802.11ax/ac/n.
If the DUT is configured for WEP or no security, this test cannot be run
and will abort before the test begins.
| Test |
Module |
Name |
Synopsis |
Verify DUT's wifi beacons contain expected mode information |
wifi.tcl |
wifi_20 |
Verify DUT’s wifi beacons contain expected mode information |
step 1. Display saved wifi beacon from DUT
step 2. Verify beacon contains expected phy mode(s)
step 3. Verify beacon contains expected privacy bit value
step 4. If WPA IE is present, validate the key management mode(s) that are
advertised
step 5. If WPA IE is present, validate the pairwise cipher modes(s) that are
advertised
step 6. If WPA IE is present, validate the group cipher modes(s) that are
advertised
step 7. Repeat steps 4 through 6 for RSN IE, if present
NOTE: For step 2, the testvar wifiBeaconPhy can be used to specify a list of
the phy modes that the DUT is expected to advertise in its beacons.
NOTE: For step 3, if the lanSecurity testvar is set to a value of "NONE",
the privacy bit should be set to 0 in all beacons from the DUT. For all
other security modes where encryption is used it should be set to a value of
1.
NOTE: For steps 4 through 7, the testvar wifiBeaconWpaMode can be used to
specify whether or not the DUT is expected to advertise support for WPA in
its beacons. If WPA support is expected and the DUT is advertising support
for it, the testvars wifiBeaconWpaKeyMgmt, wifiBeaconWpaCipher, and
wifiBeaconWpaGroupCipher can be used to specify the expected ke management,
pairwise cipher, and group cipher mode(s), respectivley, that the DUT is
expected to support. These modes are validated in steps 2 through 4 of the
test.
| Test |
Module |
Name |
Synopsis |
WiFi association stress test |
wifi.tcl |
wifi_30 |
WiFi association stress test |
step 1. Force LAN client to disassociate from DUT's AP
step 2. Force LAN client to associate to DUT's AP using initial association
parameters
step 3. Repeat steps 1 and 2 100 times
step 4. Send 10 IPv4 (and IPv6, if enabled) pings from the LAN client to a
remote host on WAN to verify connectivity
NOTE: This test verifies that the DUT is able to support a large number of
wifi reassociation cycles (100) in rapid succession and can be problematic
for some devices if repeated or run multiple times. Some devices may prevent
associations from CDRouter's LAN client during or following this test,
resulting in test failures due to a lack of connectivity with the DUT. This
behavior is implementation specific and may be a feature or a bug within the
DUT itself.
| Test |
Module |
Name |
Synopsis |
WiFi SSID scan test |
wifi.tcl |
wifi_40 |
WiFi SSID scan test |
step 1. Scan for all wireless networks matching the configured SSID
step 2. Ensure the configured SSID is found
step 3. Output all the matching wireless networks
| Test |
Module |
Name |
Synopsis |
WiFi Band Steering test |
wifi.tcl |
wifi_50 |
WiFi Band Steering test |
step 1. Disassociate the WLAN client from the access point
step 2. Perform a wireless scan for the configured lanSSID
step 3. Wait 2 seconds and repeat step 2
step 4. If networks with the configured SSID are found on bands outside
the lan80211BandSteering testvar after step 2, ensure the WLAN client
cannot associate with those networks
step 5. Ensure the WLAN client can associate with the networks found
on the band specified by the lan80211BandSteering testvar
step 6. Repeat step 1 through 5 with any additional WLAN clients
arp.tcl
ARP functional test cases
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to broadcast ARP request on LAN interface |
arp.tcl |
arp_1 |
Verify DUT responds to broadcast ARP request on LAN interface |
step 1. Send a broadcast ARP request on the LAN for the DUT's LAN IP
step 2. Verify that the DUT sends a valid ARP reply
NOTE: A broadcast ARP request is sent to the layer 2 broadcast address of
ff:ff:ff:ff:ff:ff. The ARP packet sent in this test contains the following
fields and values:
* Sender MAC address: <CDRouter's LAN MAC address>
* Sender IP address: <CDRouter's LAN IP address>
* Target MAC address: 00:00:00:00:00:00
* Target IP address: <DUT's LAN IP address>
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to unicast ARP request on LAN interface |
arp.tcl |
arp_2 |
Verify DUT responds to unicast ARP request on LAN interface |
step 1. Obtain the DUT's MAC address via ARP
step 2. Send a unicast ARP request to the DUT's MAC address obtained in
step 1 on the LAN for the DUT's LAN IP
step 3. Verify that the DUT sends a valid ARP reply
NOTE: A unicast ARP request is sent directly to the layer 2 unicast address
of the target node, which in this case is the DUT. The ARP packet sent in
this test contains the following fields and values:
* Sender MAC address: <CDRouter's LAN MAC address>
* Sender IP address: <CDRouter's LAN IP address>
* Target MAC address: 00:00:00:00:00:00
* Target IP address: <DUT's LAN IP address>
| Test |
Module |
Name |
Synopsis |
Verify DUT responds to ARP Probes on the LAN interface |
arp.tcl |
arp_3 |
Verify DUT responds to ARP Probes on the LAN interface |
step 1. Send an ARP Probe on the LAN for the DUT's LAN IP
step 2. Verify that the DUT sends a valid ARP reply
step 3. Send pings to a remote host on the WAN to verify connectivity from
LAN to WAN
NOTE: An 'ARP Probe' is a request sent to the layer 2 broadcast address of
ff:ff:ff:ff:ff:ff using a 'Sender IP address' field of 0.0.0.0. The 'Target
MAC address' field of an ARP Probe should also be set to all zeros. The ARP
Probe sent in this test contains the following fields and values:
* Sender MAC address: <CDRouter's LAN MAC address>
* Sender IP address: 0.0.0.0
* Target MAC address: 00:00:00:00:00:00
* Target IP address: <DUT's LAN IP address>
References:
IETF RFC 5227 "IPv4 Address Conflict Detection" Section 2.1: Probing an Address
https://tools.ietf.org/html/rfc5227#section-2.1
| Test |
Module |
Name |
Synopsis |
Verify DUT updates ARP cache when ARP request is received |
arp.tcl |
arp_10 |
Verify DUT updates ARP cache when ARP request is received |
step 1. Obtain the DUT's MAC address via ARP
step 2. Create a new host on the LAN (host2)
step 3. Enable DHCP on host2 and verify that an address is received
step 4. Send a gratuitous ARP for host2
step 5. Send three pings to the DUT from the host2
step 6. Verify that the DUT sends at least one ping response and that the
DUT does not send an ARP request for host2's IP address
step 7. Release host2's IP address
step 8. Create a new host on the LAN (host3) with a unique MAC and staticly
assign the same IP address obtained earlier by host2
step 9. Send ARP request for DUT's IP from host3
step 10. Send three pings to the DUT from host3
step 11. Verify that the DUT sends at least one ping response
NOTE: This test verifies that the DUT updates its ARP cache when it receives
an ARP request from a new client that is using an address that should
have an existing entry in the cache.
NOTE: The ARP request in step 9 is sent to the layer 2 broadcast address of
ff:ff:ff:ff:ff:ff and contains the following fields and values:
* Sender MAC address: <host 3's MAC address>
* Sender IP address: <host 3's IP address>
* Target MAC address: 00:00:00:00:00:00
* Target IP address: <DUT's LAN IP address>
References:
IETF RFC 826 "An Ethernet Address Resolution Protocol": Packet Reception
If the pair <protocol type, sender protocol address> is
already in my translation table, update the sender
hardware address field of the entry with the new
information in the packet and set Merge_flag to true.
https://tools.ietf.org/html/rfc826
| Test |
Module |
Name |
Synopsis |
Verify DUT updates ARP cache when ARP reply is received |
arp.tcl |
arp_11 |
Verify DUT updates ARP cache when ARP reply is received |
step 1. Obtain the DUT's MAC address via ARP
step 2. Create a new host on the LAN (host2)
step 3. Enable DHCP on host2 and verify that an address is received
step 4. Send a gratuitous ARP for host2
step 5. Send three pings to the DUT from host2
step 6. Verify that the DUT sends at least one ping response and that the
DUT does not send an ARP request for host2's IP address
step 7. Release host2's IP address
step 8. Create a new host on the LAN (host3) with a unique MAC and staticly
assign the same IP address obtained earlier by host2
step 9. Send 3 unsolicited ARP replies to the DUT from host3
step 10. Send three pings to the DUT from host3
step 11. Verify that the DUT sends at least one ping response
NOTE: This test verifies that the DUT updates its ARP cache when it receives
an unsolicited ARP reply from a new client that is using an address that
should have an existing entry in the cache.
NOTE: The ARP requests in step 9 are sent to the DUT's layer 2 hardware
address and contains the following fields and values:
* Sender MAC address: <host 3's MAC address>
* Sender IP address: <host 3's IP address>
* Target MAC address: <DUT's MAC address>
* Target IP address: <DUT's LAN IP address>
References:
IETF RFC 826 "An Ethernet Address Resolution Protocol"
If the pair <protocol type, sender protocol address> is
already in my translation table, update the sender
hardware address field of the entry with the new
information in the packet and set Merge_flag to true.
https://tools.ietf.org/html/rfc826
| Test |
Module |
Name |
Synopsis |
Verify DUT updates ARP cache when a gratuitous ARP request is received |
arp.tcl |
arp_12 |
Verify DUT updates ARP cache when a gratuitous ARP request is received |
step 1. Obtain the DUT's MAC address via ARP
step 2. Create a new host on the LAN (host2)
step 3. Enable DHCP on host2 and verify that an address is received
step 4. Send a gratuitous ARP for host2
step 5. Send three pings to the DUT from host2
step 6. Verify that the DUT sends at least one ping response and that the
DUT does not send an ARP request for host2's IP address
step 7. Release host2's IP address
step 8. Create a new host on the LAN (host3) with a unique MAC and staticly
assign the same IP address obtained earlier by host2
step 9. Send 3 gratuitous ARP requests from host3
step 10. Send three pings to the DUT from host3
step 11. Verify that the DUT sends at least one ping response
NOTE: This test verifies that the DUT updates its ARP cache when it receives
a gratuitous ARP request from a new client that is using an address that
should have an existing entry in the cache. RFC 3927 and 5227 define this
type of gratuitous ARP request as an "ARP Announcement".
NOTE: The behavior of this test is controlled by the testvar
arpSupportGratuitous. If this testvar is set to no, the test will accept
certain failure conditions.
NOTE: The ARP requests in step 9 are sent to the layer 2 broadcast address
of ff:ff:ff:ff:ff:ff and contain the following fields and values:
* Sender MAC address: <host 3's MAC address>
* Sender IP address: <host 3's IP address>
* Target MAC address: 00:00:00:00:00:00
* Target IP address: <host 3's IP address>
References:
IETF RFC 826 "An Ethernet Address Resolution Protocol"
If the pair <protocol type, sender protocol address> is
already in my translation table, update the sender
hardware address field of the entry with the new
information in the packet and set Merge_flag to true.
https://tools.ietf.org/html/rfc826
IETF RFC 2002 "IP Mobility Support" Section 4.6: ARP, Proxy ARP, and Gratuitous ARP
https://tools.ietf.org/html/rfc2002#section-4.6
IETF RFC 3927 "Dynamic Configuration of IPv4 Link-Local Addresses" Section 1.2: Terminology
https://tools.ietf.org/html/rfc3927#section-1.2
IETF RFC 5227 "IPv4 Address Conflict Detection" Section 1.1: Conventions and Terminology Used in This Document
https://tools.ietf.org/html/rfc5227#section-1.1
| Test |
Module |
Name |
Synopsis |
Verify DUT updates ARP cache when a gratuitous ARP reply is received |
arp.tcl |
arp_13 |
Verify DUT updates ARP cache when a gratuitous ARP reply is received |
step 1. Obtain the DUT's MAC address via ARP
step 2. Create a new host on the LAN (host2)
step 3. Enable DHCP on host2 and verify that an address is received
step 4. Send a gratuitous ARP for host2
step 5. Send three pings to the DUT from host2
step 6. Verify that the DUT sends at least one ping response and that the
DUT does not send an ARP request for host2's IP address
step 7. Release host2's IP address
step 8. Create a new host on the LAN (host3) with a unique MAC and staticly
assign the same IP address obtained earlier by host2
step 9. Send 3 gratuitous ARP reply packets from host3
step 10. Send three pings to the DUT from host3
step 11. Verify that the DUT sends at least one ping response
NOTE: This test verifies that the DUT updates its ARP cache when it receives
a gratuitous ARP reply from a new client that is using an address that
should have an existing entry in the cache.
NOTE: The behavior of this test is controlled by the testvar
arpSupportGratuitous. If this testvar is set to no, the test will accept
certain failure conditions.
NOTE: The ARP requests in step 9 are sent to the layer 2 broadcast address
of ff:ff:ff:ff:ff:ff and contain the following fields and values:
* Sender MAC address: <host 3's MAC address>
* Sender IP address: <host 3's IP address>
* Target MAC address: <host 3's MAC address>
* Target IP address: <host 3's IP address>
References:
IETF RFC 826 "An Ethernet Address Resolution Protocol"
If the pair <protocol type, sender protocol address> is
already in my translation table, update the sender
hardware address field of the entry with the new
information in the packet and set Merge_flag to true.
https://tools.ietf.org/html/rfc826
IETF RFC 2002 "IP Mobility Support" Section 4.6: ARP, Proxy ARP, and Gratuitous ARP
https://tools.ietf.org/html/rfc2002#section-4.6
IETF RFC 3927 "Dynamic Configuration of IPv4 Link-Local Addresses" Section 1.2: Terminology
https://tools.ietf.org/html/rfc3927#section-1.2
IETF RFC 5227 "IPv4 Address Conflict Detection" Section 1.1: Conventions and Terminology Used in This Document
https://tools.ietf.org/html/rfc5227#section-1.1
| Test |
Module |
Name |
Synopsis |
Verify DUT does not respond to bad ARP Requests |
arp.tcl |
arp_20 |
Verify DUT does not respond to bad ARP Requests |
step 1. Send a broadcast ARP request on the LAN for the loopback address
127.0.0.1
step 2. Verify that the DUT does not respond
step 3. Repeat steps 1 and 2 for the addresses 255.255.255.255, 0.0.0.0, and
224.0.0.1
| Test |
Module |
Name |
Synopsis |
Verify DUT does not leak WAN side addresses on LAN via ARP |
arp.tcl |
arp_30 |
Verify DUT does not leak WAN side addresses on LAN via ARP |
step 1. Look through the ARP history of all LAN stacks that have been
created to this point
step 2. Verify that the DUT has not sent an ARP request for its WAN gateway
on LAN
NOTE: the DUT should only send ARP requests for its default gateway on the
WAN. Sending these requests out on the LAN leaks the default gateway address
making it possible for malicious clients to spoof the default gateway and
influence the DUT's routing table. This can lead to a DoS situation for
other LAN clients.
There are several existing CVEs that mention this type of issue:
CVE-1999-0763 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0763
CVE-1999-0667 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0667
NOTE: This is a new type of CDRouter test that analyzes data generated from
previous tests. In this case the data being analyzed is the ARP history of
all LAN clients that have been created up to the point where this test was
executed during a particular test run. To ensure that the largest possible
data set is analyzed, this test should be executed at the end of a test run
or at multiple points during a test run.
| Test |
Module |
Name |
Synopsis |
Verify DUT does not leak LAN side addresses on WAN via ARP |
arp.tcl |
arp_31 |
Verify DUT does not leak LAN side addresses on WAN via ARP |
step 1. Look through the ARP history of all WAN stacks that have been
created to this point
step 2. Verify DUT has not sent ARP request for LAN side hosts
Reference:
The DUT should only send ARP requests for LAN clients on the LAN. Sending
these requests out on the WAN leaks LAN side addresses and could make the
DUT vulnerable to spoofing LAN side hosts from the WAN.
There are several existing CVEs that mention this type of issue:
CVE-1999-0763 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0763
CVE-1999-0667 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0667
NOTE: This is a new type of CDRouter test that analyzes data generated from
previous tests. In this case the data being analyzed is the ARP history of
all LAN clients that have been created up to the point where this test was
executed during a particular test run. To ensure that the largest possible
data set is analyzed, this test should be executed at the end of a test run
or at multiple points during a test run.
| Test |
Module |
Name |
Synopsis |
Verify DUT ARP mode behavior - open, restricted, strict |
arp.tcl |
arp_40 |
Verify DUT ARP mode behavior - open, restricted, strict |
step 1. Send ARP request for DUT's WAN IP address on the LAN
step 2. Verify the DUT's expected ARP behavior regarding the request sent
in step 1 according to the value of the arpMode testvar
step 3. Send ARP request for DUT's LAN IP address on the LAN using a client
with an address that is not within the LAN subnet
step 4. Verify the DUT's expected ARP behavior regarding the request sent
in step 3 according to the value of the arpMode testvar
NOTE: The arpMode testvar specifies the expected ARP behavior of the DUT,
which can be set to one of three values:
* open: The DUT will reply for any local target IP address, configured
on any interface.
* restricted: The DUT will reply only if the target IP address is a local
address configured on the incoming interface.
* strict: The DUT will reply only if the target IP address is a local
address configured on the incoming interface and if the
sender's IP address is within the same subnet.
The recommended ARP behavior is restricted or strict.
NOTE: For more information please see the Linux kernel documentation for the
arp_ignore flag:
https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
| Test |
Module |
Name |
Synopsis |
Verify DUT ignores spoofed ARP reply for WAN gateway |
arp.tcl |
arp_50 |
Verify DUT ignores spoofed ARP reply for WAN gateway |
step 1. Obtain the DUT's MAC address via ARP
step 2. Create a new host on the LAN (host2)
step 3. Enable DHCP on host2 and verify that an address is received
step 4. Send 3 spoofed ARP replies from host2 to the DUT for the DUT's WAN
default gateway
step 5. Verify the DUT ignored the ARP replies sent in step 4 by testing LAN
to WAN connectivity using pings
step 6. Verify that the pings sent in step 5 are successful
step 7. Restore the DUT's WAN gateway ARP entry by sending an ARP request
for the DUT's IP on the WAN
step 8. Verify LAN to WAN connectivity through the DUT using pings
References:
IETF RFC 5227 "IPv4 Address Conflict Detection" Section 2.1: Probing an Address
https://tools.ietf.org/html/rfc5227#section-2.1
| Test |
Module |
Name |
Synopsis |
Verify DUT handles a large number of ARP requests with unique MAC addresses |
arp.tcl |
arp_60 |
Verify DUT handles a large number of ARP requests with unique MAC addresses |
step 1. Send a unicast ARP request on the LAN for the DUT's LAN IP
step 2. Repeat for 500 unique source MAC addresses (only 20 unique source
MAC for wireless interfaces)
step 3. Send a broadcast ARP request on the LAN for the DUT's LAN IP
step 4. Verify an ARP reply is received
| Test |
Module |
Name |
Synopsis |
Verify DUT handles a large number of ARP replies with unique MAC addresses |
arp.tcl |
arp_61 |
Verify DUT handles a large number of ARP replies with unique MAC addresses |
step 1. Send a unicast ARP reply to the DUT on the LAN
step 2. Repeat for 500 unique source MAC addresses (only 20 unique source
MAC for wireless)
step 3. Send a broadcast ARP request on the LAN for the DUT's LAN IP
step 4. Verify an ARP reply is received
