CDRouter IKE Test Summaries (Full)

Test Case Descriptions

Modules: 2
Test Cases: 58

Below is a full description of the testcases in each module

`ike.tcl`

IKEv1 site-to-site tunnel testing

Test	Name	Synopsis
`Verify gateway can act as tunnel initiator`	`ike_1`	Verify gateway can act as tunnel initiator



    step 1. Delete all existing Phase 1 and Phase 2 SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Send ICMP Echo Request from the LAN that matches the tunnel destination
    step 4. Wait up to 120 seconds for tunnel to be established
    step 5. Verify traffic can be sent over the tunnel in both directions

    NOTE: This test verifies that device under test can initiate IKE Phase 1
    exchanges (Main Mode or Aggressive Mode) and Phase 2 exchanges (Quick Mode)
    to establish a tunnel when traffic is presented that matches the tunnel
    configuration.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway can act as tunnel responder`	`ike_2`	Verify gateway can act as tunnel responder



    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate Main Mode
    step 4. Verify Main Mode exchange completes
    step 5. Initiate Quick Mode
    step 6. Verify Quick Mode exchange completes
    step 7. Verify traffic can be sent over the tunnel in both directions

    NOTE: This test verifies that the device under test can act as a
    responder in both a Main Mode and Quick Mode exchange.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify traffic is not sent in the clear when all Phase 2 SAs are deleted`	`ike_4`	Verify traffic is not sent in the clear when all Phase 2 SAs are deleted



    step 1. Delete all existing Quick Mode SAs for the tunnel
    step 2. Configure CDRouter to ignore any new Quick Mode packets
    step 3. Send traffic from LAN that matches tunnel
    step 4. Verify traffic is not sent in the clear out WAN interface

    NOTE: When a site-to-site tunnel is configure on the device under
    test, traffic that matches the tunnel should not be sent in the clear
    when the tunnel is down. This test brings the tunnel to a down state by
    deleting all of the Quick Mode SAs but leaving any existing Main Mode SAs.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify traffic is not sent in the clear when all Phase 1 and 2 SAs are deleted`	`ike_5`	Verify traffic is not sent in the clear when all Phase 1 and 2 SAs are deleted



    step 1. Delete all existing Quick Mode and Main Mode SAs for the tunnel
    step 2. Configure CDRouter to ignore any new Main Mode and Quick Mode packets
    step 3. Send traffic from LAN that matches tunnel
    step 4. Verify traffic is not sent in the clear out WAN interface

    NOTE: When a site-to-site tunnel is configured on the device under
    test, traffic that matches the tunnel should not be sent in the
    clear when the tunnel is down. This test brings the tunnel to a down
    state by deleting all of the Main Mode and Quick Mode SAs.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway switches to new Phase 2 SA after peer initiates new Phase 2 SA`	`ike_10`	Verify gateway switches to new Phase 2 SA after peer initiates new Phase 2 SA



    step 1. Establish a new Quick Mode SA using the existing Main Mode SA
    step 2. Verify a new Quick Mmode SA is established
    step 3. Wait ikeNewQuickModeDelay milliseconds
    step 4. Send traffic from LAN that matches tunnel
    step 5. Verify router switches to new Quick Mode SA
    step 6. Repeat 2 additional Quick Modes


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway switches to new Phase 2 SA after peer initiates new Phase 1 and 2 SA`	`ike_12`	Verify gateway switches to new Phase 2 SA after peer initiates new Phase 1 and 2 SA



    step 1. Establish a new Main Mode SA
    step 2. Establish a new Quick Mode SA using new Main Mode
    step 3. Verify a new Quick Mode SA is established
    step 4. Wait ikeNewQuickModeDelay milliseconds
    step 5. Send traffic from LAN that matches tunnel
    step 6. Verify router switches to new Quick Mode SA


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify deletion of old Phase 1 and 2 SAs does not stop traffic over new SA`	`ike_14`	Verify deletion of old Phase 1 and 2 SAs does not stop traffic over new SA



    step 1. Establish a new Main Mode SA
    step 2. Establish a new Quick Mode SA using new Main Mode
    step 3. Verify a new Quick Mode SA is established
    step 4. Wait ikeNewQuickModeDelay milliseconds
    step 5. Send traffic from LAN that matches tunnel
    step 6. Verify router switches to new Quick Mode SA
    step 7. Delete old Quick Mode SAs
    step 8. Delete old Main Mode SAs
    step 9. Verify tunnel traffic from LAN is still forwarded using new SA


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify old Phase SA continues to work after new Phase 2 SA is initiated`	`ike_16`	Verify old Phase SA continues to work after new Phase 2 SA is initiated



    step 1. Delete all Phase 1 and Phase 2 SAs
    step 2. Establish a new Phase 1 and Phase 2
    step 3. Verify tunnel traffic is using the new Phase 2 SA
    step 4. Initiate a new Phase 2 SA using the same Phase 1
    step 5. Send traffic from LAN that matches tunnel
    step 6. Send return traffic back using original Phase 2 SA
    step 7. Verify traffic on the original Phase 2 SA is still forwarded


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway has retransmission strategy for Phase 1 establishment`	`ike_30`	Verify gateway has retransmission strategy for Phase 1 establishment



    step 1. Delete all Quick Mode and Main Mode SAs
    step 2. Initiate traffic from the LAN that matches tunnel
    step 3. Verify Phase 1 packet is sent by IKE gateway
    step 4. Do not respond to Phase 1 packet
    step 5. Continue to send traffic on the LAN
    step 6. Wait for additional Phase 1 packet from IKE gateway
    step 7. Continue until 3 Phase 1 packets have been sent

    NOTE: This test will verify that the router continues to send Phase 1
    packets to initiate a tunnel that is down. The test will wait up to 120
    seconds to 3 Phase 1 packets to be sent.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway has retransmission strategy for Phase 2 establishment`	`ike_31`	Verify gateway has retransmission strategy for Phase 2 establishment



    step 1. Delete all Quick Mode and Main Mode SAs
    step 2. Initiate traffic from the LAN that matches tunnel
    step 3. Verify new Phase 1 is established
    step 4. Continue to send traffic on the LAN
    step 5. Wait for additional Phase 2 packet
    step 6. Do not respond to Phase 2 packet
    step 7. Wait for Phase 2 packet to be retransmitted

    NOTE: This test will verify that the router retransmits the Phase 2 packets
    when establishing a new quickmode SA. The test will wait up to 280 seconds
    for 2 Phase 2 packets to be sent. The test fails if the router restarts the
    exchange by sending a new Phase 1 packet.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway sends Phase 1 delete notification after Phase 1 lifetime expires (initiator)`	`ike_40`	Verify gateway sends Phase 1 delete notification after Phase 1 lifetime expires (initiator)



    step 1. Delete all existing Phase 1 and Phase 2 SAs
    step 2. Send traffic on LAN to force gateway to initiate new Phase 1 and 2
    step 3. Wait for SA lifetime to expire
    step 4. Verify router sends a DELETE Notification for this Phase 1 SA


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway sends Phase 2 delete notification after Phase 2 lifetime expires (initiator)`	`ike_41`	Verify gateway sends Phase 2 delete notification after Phase 2 lifetime expires (initiator)



    step 1. Delete all existing Phase 1 and Phase 2 SAs
    step 2. Send traffic on LAN to force gateway to initiate new Phase 1 and 2
    step 3. Wait for the Phase 2 SA lifetime to expire
    step 4. Verify router sends a DELETE Notification for this Phase 2 SA


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway deletes Phase 1 SA after Phase 1 lifetime expires (initiator)`	`ike_42`	Verify gateway deletes Phase 1 SA after Phase 1 lifetime expires (initiator)



    step 1. Delete all existing Phase 1 and Phase 2 SAs
    step 2. Send traffic on LAN to force gateway to initiate new Phase 1 and 2
    step 3. Wait for Phase 1 SA to expire
    step 4. Router should delete the expired Phase 1 SA
    step 5. Send traffic from LAN to force tunnel up
    step 6. Verify router attempts to establish new Phase 1


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway deletes Phase 2 SA after Phase 2 lifetime expires (initiator)`	`ike_43`	Verify gateway deletes Phase 2 SA after Phase 2 lifetime expires (initiator)



    step 1. Delete all existing Phase 1 and Phase 2 SAs
    step 2. Send traffic on LAN to force gateway to initiate new Phase 1 and 2
    step 3. Wait for the Phase 2 SA lifetime to expire
    step 4. Router should delete the Phase 2 SA
    step 5. Send traffic from LAN that matches tunnel
    step 6. Verify traffic is not sent on expired Phase 2 SA
    step 7. Verify traffic is not sent in the clear


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway sends delete notification after Phase 1 lifetime expires (responder)`	`ike_50`	Verify gateway sends delete notification after Phase 1 lifetime expires (responder)



    step 1. Delete all existing Phase 1 and Phase 2 SAs
    step 2. Estabalish a new Phase 1 SA to that gateway is in responder mode
    step 3. Wait for SA lifetime to expire
    step 4. Verify router sends a DELETE Notification for this Phase 1 SA

    NOTE: This test uses the value of testvar 'ikeMinimumLifetime' to
    set the value of the lifetime for the new Phase 1. The lifetime value is
    in seconds and defaults to 20. Some implementations may not allow a
    lifetime to be created if it is smaller than the router's configured lifetime.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway sends delete notification after Phase 2 lifetime expires (responder)`	`ike_51`	Verify gateway sends delete notification after Phase 2 lifetime expires (responder)



    step 1. Delete all existing Phase 1 and Phase 2 SAs
    step 2. Establish a new Phase 1 SA
    step 3. Establish a new Phase 2 SA so that gateway is in responder mode
    step 4. Wait for the Phase 2 SA lifetime to expire
    step 5. Verify router sends a DELETE Notification for this Phase 2 SA

    NOTE: This test uses the value of testvar 'ipsecMinimumLifetime' to
    set the value of the lifetime for the new Phase 1. The lifetime value is
    in seconds and defaults to 20. Some implementations may not allow a
    lifetime to be created if it is smaller than the router's configured lifetime.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway deletes Phase 1 SA after Phase 1 lifetime expires (responder)`	`ike_52`	Verify gateway deletes Phase 1 SA after Phase 1 lifetime expires (responder)



    step 1. Delete all existing Phase 1 and Phase 2 SAs
    step 2. Establish new Phase 1 SA
    step 3. Ignore any Phase 2 initiation attempts
    step 4. Wait for Phase 1 SA to expire
    step 5. Router should delete the expired Phase 1 SA
    step 6. Send traffic from LAN to force tunnel up
    step 7. Verify router attempts to establish new Phase 1

    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway deletes Phase 2 SA after Phase 2 lifetime expires (responder)`	`ike_53`	Verify gateway deletes Phase 2 SA after Phase 2 lifetime expires (responder)



    step 1. Delete all existing Phase 1 and Phase 2 SAs
    step 2. Establish a new Phase 1 SA
    step 3. Establish a new Phase 2 SA
    step 4. Ignore any new Phase 1 or Phase 2 attempts
    step 5. Wait for the Phase 2 SA lifetime to expire
    step 6. Router should delete the Phase 2 SA
    step 7. Send traffic from LAN that matches tunnel
    step 8. Verify traffic is not sent on expired Phase 2 SA
    step 9. Verify traffic is not sent in the clear


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway sends NOTIFY message when tunnel specification does not match`	`ike_70`	Verify gateway sends NOTIFY message when tunnel specification does not match



    step 1. Configure CDRouter to use an unknown subnet for Phase 2 proposal
    step 2. Bring down all existing Phase 1 and 2 SAs
    step 3. Initiate new Phase 1 SA
    step 4. Initiate a new Phase 2 exchange with the gateway
    step 5. Verify the gateway sends a NOTIFY message with NO-PROPOSAL-CHOSEN
            or INVALID-ID-INFORMATION

    NOTE: The sending of a Notify payload is not required but is commonly supported
    to help administrators determine VPN configuration mismatches.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 2408 "Internet Security Association and Key Management Protocol (ISAKMP)" Section 5.4: Security Association Payload Processing

    https://tools.ietf.org/html/rfc2408#section-5.4

Test	Name	Synopsis
`Verify gateway reuses Phase 1 SA when Phase 2 setup fails`	`ike_72`	Verify gateway reuses Phase 1 SA when Phase 2 setup fails



    step 1. Delete all existing Phase 1 and 2 SAs
    step 2. Initiate a new Phase 1 SA
    step 3. Initiate a new Phase 2 SA with unaccpetable proposal
    step 4. Send traffic on LAN interface to try to establish the tunnel
    step 5. Verify gateway does not create additional Phase 1 SAs


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway reuses Phase 1 SA when Phase 2 is deleted`	`ike_73`	Verify gateway reuses Phase 1 SA when Phase 2 is deleted



    step 1. Delete all existing Phase 2 SAs
    step 2. Initiate traffic on the LAN to force gateway to create new Phase 2
    step 3. Verify router uses existing Phase 1 and does not create new Phase 1


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway deletes existing Phase 2 SAs when INITIAL-CONTACT message is received during new Phase 1`	`ike_80`	Verify gateway deletes existing Phase 2 SAs when INITIAL-CONTACT message is received during new Phase 1



    step 1. Verify Phase 1 and Phase 2 SAs exist
    step 2. Initiate new Phase 1 using INITIAL-CONTACT
    step 3. Gateway should delete all existing Phase 2 SAs
    step 4. Ignore any Phase 2 requests
    step 5. Initiate traffic from LAN for tunnel
    step 6. Verify no traffic is sent on the tunnel since no Phase 2 SAs exist

    NOTE: This test is skipped if Aggressive Mode tunnels are configured.
    When Aggressive Mode is used, INITIAL-CONTACT messages can only sent
    in Phase 2 or Informational messages after the Phase 1 SA is established.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway deletes existing Phase 2 SAs when INITIAL-CONTACT message is received during new Phase 2`	`ike_81`	Verify gateway deletes existing Phase 2 SAs when INITIAL-CONTACT message is received during new Phase 2



    step 1. Verify Phase 1 and Phase 2 SAs exist
    step 2. Initiate new Phase 1
    step 3. Initiate new Phase 2 with INITIAL-CONTACT
    step 4. Gateway should delete all existing Phase 2 SAs
    step 5. Initiate traffic from LAN for tunnel
    step 6. Verify no traffic is sent on the tunnel since no Phase 2 SAs exist


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify INITIAL-CONTACT is ignored if not protected under IKE SA`	`ike_82`	Verify INITIAL-CONTACT is ignored if not protected under IKE SA



    step 1. Verify Phase 1 and Phase 2 SAs exist
    step 2. Initiate new Phase 1 using INITIAL-CONTACT in first packet (unprotected)
    step 3. Gateway should not delete all existing Phase 2 SAs
    step 4. Verify tunnel is still operational

    RFC 2407 IP Security Domain of Interpretation
    Section 4.6.3 IPSEC Notify Message Types

    NOTE: All Notify messages must be protect by an IKE SA including
    the INITIAL-CONTACT message. The first packet in a new Main Mode
    exchange is not protected and could possibly be spoofed.

    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway deletes existing Phase 2 SAs when INITIAL-CONTACT message is received from NOTIFY`	`ike_85`	Verify gateway deletes existing Phase 2 SAs when INITIAL-CONTACT message is received from NOTIFY


    step 1. Verify Phase 1 and Phase 2 SAs exist
    step 2. Initiate new Phase 1
    step 3. After Phase 1 is established, send a NOTIFY message with INITIAL-CONTACT
    step 4. Gateway should delete any existing SAs
    step 5. Initiate traffic from LAN for tunnel
    step 6. Verify no traffic is sent on the tunnel since no Phase 2 SAs exist


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify the maximum number of Phase 2 SAs that can be established with remote gateway`	`ike_100`	Verify the maximum number of Phase 2 SAs that can be established with remote gateway



    step 1. Verify existing Phase 1 and Phase 2 SAs exist
    step 2. Create ikeMaxPhase2SA additional Phase 2 SAs
    step 3. Verify all Phase 2 SAs are created

    NOTE: The testvar 'ikeMaxPhase2SA' controls how many total Phase 2 SAs
    will be created. The default value is 20 Phase 2 SAs.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify Phase 1 SA can be established when unknown Vendor IDs are included`	`ike_110`	Verify Phase 1 SA can be established when unknown Vendor IDs are included



    step 1. Verify existing Phase 1 and Phase 2 SAs exist
    step 2. Initiate a new Phase 1 SA include 3 unknonwn vendor IDs
    step 3. Initiate a new Phase 2 SA
    step 4. Verify gateway switches to new Phase 2 SA


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway rejects Phase 2 proposals with unknown payloads`	`ike_122`	Verify gateway rejects Phase 2 proposals with unknown payloads



    step 1. Verify existing Phase 1 and Phase 2 SAs exist
    step 2. Initiate new Phase 2 SA using bad payload
    step 3. Verify Phase 2 SA is not established
    step 4. If NOTIFY message is received, verify type is PAYLOAD-MALFORMED
            or INVALID-PAYLOAD-TYPE


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 2408 "Internet Security Association and Key Management Protocol (ISAKMP)" Section 5.3: Generic Header Processing

    https://tools.ietf.org/html/rfc2408#section-5.3

Test	Name	Synopsis
`Verify starting ESP sequence number for new phase SA is 1`	`ike_130`	Verify starting ESP sequence number for new phase SA is 1



    step 1. Find existing Phase 1 SA
    step 2. Initiate a new Phase 2 SA
    step 3. Initiate ICMP Echo Request from LAN over the tunnel with inbound
    step 4. Verify first IPSEC ESP packet has a sequence number of 1


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 3.3.3: Sequence Number Generation

    https://tools.ietf.org/html/rfc2406#section-3.3.3

Test	Name	Synopsis
`Verify gateway anti-replay detection`	`ike_135`	Verify gateway anti-replay detection



    step 1. Find existing Phase 1 SA
    step 2. Initiate a new Phase 2 SA
    step 3. Initiate ICMP Echo  Request from LAN over the tunnel with inbound
            starting ESP sequence number of 1
    step 4. Verify ICMP Echo Request is successful
    step 5. Reset the ESP sequence number to 1
    step 6. Initiate another ICMP Echo Request from LAN over the tunnel
    step 7. Verify inbound ESP packets are not forwarded to LAN


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 3.3.4: Sequence Number Verification

    https://tools.ietf.org/html/rfc2406#section-3.3.4

Test	Name	Synopsis
`Verify out of sequence ESP packets to not trigger replay detection`	`ike_136`	Verify out of sequence ESP packets to not trigger replay detection



    step 1. Find existing Phase 1 SA
    step 2. Initiate a new Phase 2 SA
    step 3. Send 3 UDP Echo Requests from the LAN over tunnel
    step 4. Send UDP Echo Replies back over the tunnel using out of
            order ESP sequence numbers
    step 5. Verify UDP packets are forwarded to the LAN

    NOTE: The gateway must have a SPI window size of at least 3 packets
    to pass this test.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 3.3.4: Sequence Number Verification

    https://tools.ietf.org/html/rfc2406#section-3.3.4

Test	Name	Synopsis
`Verify IPSEC window moves forward`	`ike_140`	Verify IPSEC window moves forward



    step 1. Find the existing Phase 1 SA
    step 2. Establish a new Phase 2 SA
    step 3. Set the outbound ESP sequence number to 0x5000000
    step 4. Initiate ICMP Echo Request from LAN over the tunnel
    step 5. Set the outbound ESP sequence number back to 0x1000000
    step 6. Initiate ICMP Echo Request from LAN over the tunnel
    step 7. Verify WAN IPSEC ESP packets with old sequence number
            are not forwarded to LAN


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 3.3.4: Sequence Number Verification

    https://tools.ietf.org/html/rfc2406#section-3.3.4

Test	Name	Synopsis
`Verify gateway responds to Dead Peer detection R-U-THERE requests`	`ike_200`	Verify gateway responds to Dead Peer detection R-U-THERE requests



    step 1. Find existing Phase 1 SA
    step 2. Send R-U-THERE request
    step 3. Verify R-U-THERE ACK is received
    step 4. Continue up to 5 R-U-THERE requests

    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway supports peer IDs of type ID_FQDN`	`ike_300`	Verify gateway supports peer IDs of type ID_FQDN



    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate a Phase 1 exchange with an ID type of ID_FQDN
    step 4. Verify Phase 1 is successful
    step 5. Initiate a Phase 2 exchange
    step 6. Verify Phase 2 is successful
    step 7. Verify traffic can be sent over the tunnel in both directions

    NOTE: By default, this test uses a FQDN of "fqdn-test.cdroutertest.com". A different
    FQDN name can be used by configuring the testvar 'ike_FQDN'.

    testvar ike_FQDN fqdn-test.cdroutertest.com


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway supports peer IDs of type ID_USER_FQDN`	`ike_301`	Verify gateway supports peer IDs of type ID_USER_FQDN



    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate a Phase 1 exchange with an ID type of ID_USER_FQDN
    step 4. Verify Phase 1 is successful
    step 5. Initiate a Phase 2 exchange
    step 6. Verify Phase 2 is successful
    step 7. Verify traffic can be sent over the tunnel in both directions

    NOTE: By default, this test uses a USER_FQDN of "cdrouter@fqdn-test.cdroutertest.com".
    A different USER_FQDN name can be used by configuring the testvar 'ike_USER_FQDN'.

    testvar ike_USER_FQDN cdrouter@fqdn-test.cdroutertest.com


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway gracefully fails when ID type is unknown`	`ike_302`	Verify gateway gracefully fails when ID type is unknown



    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate a Phase 1 exchange with an ID type of 0x57
    step 4. Verify Phase 1 is not successful

    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway ignores unknown transform in Phase 1 proposal`	`ike_310`	Verify gateway ignores unknown transform in Phase 1 proposal



    step 1. Delete all existing Phase 2 and Phase 1 SAs
    step 2. Initiate a new Main Mode using an unknown transform
            followed by a valid transform.
    step 3. The gateway should select the second transform that
            is valid
    step 4. Verify Main Mode completes
    step 5. Verify Quick Mode completes
    step 6. Verify the tunnel is operational

    NOTE: This test is skipped if the maximum number of transforms
    supported is not greater than 1. The testvar 'ikeMaxTransforms'
    can be used to configure the maximum number of transforms that
    CDRouter will send in a Phase 1 Main Mode proposal.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 2408 "Internet Security Association and Key Management Protocol (ISAKMP)" Section 5.6: Transform Payload Processing

    https://tools.ietf.org/html/rfc2408#section-5.6

Test	Name	Synopsis
`Verify gateway can find valid transform in large list of transforms`	`ike_311`	Verify gateway can find valid transform in large list of transforms



    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate Phase 1 with up to 20 unknown transforms in Phase 1
            followed by 1 valid transform
    step 4. Router should search transform list and find valid transform
    step 5. Verify Phase 1 completes
    step 6. Initiate Phase 2
    step 7. Verify traffic can be sent over the tunnel in both directions

    NOTE: This test is skipped if the maximum number of transforms
    supported is not greater than 1. The testvar 'ikeMaxTransforms'
    can be used to configure the maximum number of transforms that
    CDRouter will send in a Phase 1 proposal.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 2408 "Internet Security Association and Key Management Protocol (ISAKMP)" Section 5.6: Transform Payload Processing

    https://tools.ietf.org/html/rfc2408#section-5.6

Test	Name	Synopsis
`Verify gateway recovers gracefully if no valid transform is found in proposal`	`ike_312`	Verify gateway recovers gracefully if no valid transform is found in proposal



    step 1. Delete all existing Phase 1 and Phase 2 SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate a new Phase 1 exchange using unknown transform
    step 4. Phase 1 exchange should fail
    step 5. Initiate a new Phase 1 exchange using a valid transform
    step 6. Verify Phase 1 exchange is successful
    step 7. Initiate a new Phase 2 exchange
    step 8. Verify traffic can be sent over the tunnel in both directions


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway ignores unknown transform in Phase 2 proposal`	`ike_320`	Verify gateway ignores unknown transform in Phase 2 proposal



    step 1. Delete all existing mainmode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate Phase 1
    step 4. Verify Phase 1 exchange completes
    step 5. Initiate Phase 2 with 1 unknown transforms followed
            by 1 valid transform
    step 6. Verify Phase 2 exchange completes
    step 7. Verify traffic can be sent over the tunnel in both directions

    NOTE: This test creates the first transform with an SA attribute of
    of 0xfe which is currently not defined.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway handles large transform list during Phase 2`	`ike_321`	Verify gateway handles large transform list during Phase 2



    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate Phase 1
    step 4. Verify Phase 1 exchange completes
    step 5. Initiate Phase 2 with 11 transforms
    step 6. Verify Phase 2 exchange completes
    step 7. Verify traffic can be sent over the tunnel in both directions


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify new Phase 2 can be established with SA Lifetime using both seconds and bytes`	`ike_330`	Verify new Phase 2 can be established with SA Lifetime using both seconds and bytes



    step 1. Delete all existing Phase 1 and Phase 2 SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate a new Phase 1 exchange
    step 4. Initiate a new Phase 2 exchange using an SA lifetime that
            includes attributes for SA Life Type of both seconds and bytes
    step 5. Verify Phase 2 exchange is successful
    step 6. Verify traffic can be sent over the tunnel in both directions


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify Phase 2 SA setup using small Nonce sizes (8)`	`ike_350`	Verify Phase 2 SA setup using small Nonce sizes (8)



    step 1. Delete all existing Phase 1 and Phase 2 SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate a new Phase 1 exchange using a Nonce size of 8
    step 4. Verify Phase 1 is successful
    step 5. Initiate a new Phase 2 exchange
    step 6. Verify Phase 2 is successful
    step 7. Verify traffic can be sent over the tunnel in both directions

    NOTE: IKE implementations must support Nonce sizes from 8 to 256 bytes.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify Phase 2 SA setup using large Nonce sizes (256)`	`ike_351`	Verify Phase 2 SA setup using large Nonce sizes (256)



    step 1. Delete all existing Phase 1 and Phase 2 SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate a new Phase 1 exchange using a Nonce size of 256
    step 4. Verify Phase 1 is successful
    step 5. Initiate a new Phase 2 exchange
    step 6. Verify Phase 2 is successful
    step 7. Verify traffic can be sent over the tunnel in both directions

    NOTE: IKE implementations must support Nonce sizes from 8 to 256 bytes.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway can act as tunnel initiator and responder at the same time`	`ike_360`	Verify gateway can act as tunnel initiator and responder at the same time



    step 1. Send delete for all Phase 2 and Phase 1 SAs
    step 2. Initiate traffic on the LAN to force router to initiate
            and new Phase 1 on the LAN
    step 3. Wait for Phase 1 packet on the WAN
    step 4. Initiate a new Phase 1 exchange on the WAN
    step 5. Verify Phase 1 exchange is successful
    step 6. Initiate a Phase 2 exchange
    step 7. Verify Phase 2 exchange is successful
    step 8. Verify traffic can be sent over the tunnel in both directions

    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway handles Diffie-Hellman public keys with leading zeros`	`ike_365`	Verify gateway handles Diffie-Hellman public keys with leading zeros



    step 1. Delete all existing mainmode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate Main Mode using a DH public key that starts with
            leading zeros ('00')
    step 4. Verify Main Mode exchange completes
    step 5. Initiate Quick Mode
    step 6. Verify Quick Mode exchange completes
    step 7. Verify traffic can be sent over the tunnel in both directions

    NOTE: The Diffie-Hellman public value passed in a KE payload, in either a
    Phase 1 or Phase 2 exchange, MUST be the length of the negotiated
    Diffie-Hellman group enforced, if necessary, by pre-pending the
    value with zeros.

    NOTE: Some IKE implementations do not maintain the leading '00' if the
    public key that is generated starts with '00'. This leads to
    interoperablity problems since the keying material produced will not
    match on both sides.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 2631 "Diffie-Hellman Key Agreement Method" Section 2.1.2: Generation of Keying Material

    https://tools.ietf.org/html/rfc2631#section-2.1.2

Test	Name	Synopsis
`Verify gateway handles ephemeral Diffie-Hellman shared secret with leading zeros`	`ike_366`	Verify gateway handles ephemeral Diffie-Hellman shared secret with leading zeros



    step 1. Delete all existing Phase 1 and Phase 2 SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Send ICMP echo from the LAN that matches the tunnel destination
    step 4. Wait up to 120 seconds for tunnel to be established
    step 5. When Main Mode is initiated, seach for a DH key pair
            based on the gateways public key that will produce a leading
            '00' for the epermeral key.
    step 6. Verify tunnel is established
    step 7. Verify traffic can be sent over the tunnel in both directions

    NOTE: The Diffie-Hellman public value passed in a KE payload, in either a
    Phase 1 or Phase 2 exchange, MUST be the length of the negotiated
    Diffie-Hellman group enforced, if necessary, by pre-pending the
    value with zeros.

    NOTE: Some IKE implementations do not maintain the leading '00' if the
    epermeral key that is generated starts with '00'. This leads to
    interoperablity problems since the keying material produced will not
    match on both sides.

    NOTE: RFC 2631 states that leading zeros MUST be preserved when computing
    the shared secret (ephemeral key). Versions based on OpenSSL may
    experience problems since the DH_compute_key function does not maintain
    any leading zeros when returning the length of the key.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 2631 "Diffie-Hellman Key Agreement Method" Section 2.1.2: Generation of Keying Material

    https://tools.ietf.org/html/rfc2631#section-2.1.2

Test	Name	Synopsis
`Verify gateway accepts fragmented IKE packets`	`ike_370`	Verify gateway accepts fragmented IKE packets



    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Set MTU of CDRouter gateway to 108 bytes
    step 4. Initiate Main Mode
    step 5. Verify Main Mode exchange completes
    step 6. Initiate Quick Mode
    step 7. Verify Quick Mode exchange completes
    step 8. Restore default MTU
    step 9. Verify traffic can be sent over the tunnel in both directions


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway accepts fragmented IKE packets in reverse order`	`ike_371`	Verify gateway accepts fragmented IKE packets in reverse order



    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Set MTU of CDRouter gateway to 108 bytes
    step 4. Initiate Phase 1 sending IPv4 fragments in reverse order
    step 5. Verify Main Mode exchange completes
    step 6. Initiate Quick Mode
    step 7. Verify Quick Mode exchange completes
    step 8. Restore default MTU
    step 9. Verify traffic can be sent over the tunnel in both directions


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test	Name	Synopsis
`Verify gateway ignores IKE packets with an invalid UDP checksum`	`ike_380`	Verify gateway ignores IKE packets with an invalid UDP checksum



    step 1. Delete all existing Phase 2 and Phase 1 SAs
    step 2. Initiate a Phase 1 exchange including invalid UDP checksums
    step 3. Router should ignore IKE packets with invalid checksum
    step 4. Verify Phase 1 SA is not established

    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

`ike-natt.tcl`

IKEv1 NAT-Traversal testing

Test	Name	Synopsis
`Verify gateway detects NAT and uses NAT-T in initiator mode`	`ike_natt_1`	Verify gateway detects NAT and uses NAT-T in initiator mode



    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Send ICMP Echo Request from the LAN that matches the tunnel destination
    step 4. Wait up to 120 seconds for tunnel to be established
    step 5. Include NAT-T Vendor ID and NAT-D payloads that indicate NAT
            is present
    step 6. Once tunnel is established, verify tunnel encapsulation is UDP
            for traffic received from VPN gateway
    step 7. Initiate traffic from LAN over tunnel
    step 8. Verify ESP traffic is using correct UDP encapsulation based
            on the configured version of NAT-T


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 3947 "Negotiation of NAT-Traversal in the IKE"

    https://tools.ietf.org/html/rfc3947

    IETF RFC 3948 "UDP Encapsulation of IPsec ESP Packets"

    https://tools.ietf.org/html/rfc3948

Test	Name	Synopsis
`Verify gateway detects NAT and uses NAT-T in responder mode`	`ike_natt_2`	Verify gateway detects NAT and uses NAT-T in responder mode



    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate Main Mode
    step 4. Verify Main Mode exchange completes
    step 5. Initiate Quick Mode
    step 6. Verify Quick Mode exchange completes
    step 7. Verify traffic can be sent over the tunnel in both directions
    step 8. Include NAT-T Vendor ID and NAT-D payloads that indicate NAT
            is present
    step 9. Once tunnel is established, verify tunnel encapsulation is UDP
            for traffic received from VPN gateway
    step 10. Initiate traffic from LAN over tunnel
    step 11. Verify ESP traffic is using correct UDP encapsulation based
             on the configured version of NAT-T


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 3947 "Negotiation of NAT-Traversal in the IKE"

    https://tools.ietf.org/html/rfc3947

    IETF RFC 3948 "UDP Encapsulation of IPsec ESP Packets"

    https://tools.ietf.org/html/rfc3948

Test	Name	Synopsis
`Verify gateway sends NAT-T Keep Alives in initiator mode`	`ike_natt_10`	Verify gateway sends NAT-T Keep Alives in initiator mode



    step 1. Delete all existing Phase 1 and Phase 2 SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Send ICMP Echo Request from the LAN that matches the tunnel destination
    step 4. Wait up to 120 seconds for tunnel to be established
    step 5. Use NAT-T detection payload that indicates NAT in both directions
    step 6. Verify traffic can be sent over the tunnel in both directions
    step 7. Verify IKE Keep-alive packets are sent every ikeKeepAlive seconds

    NOTE: The expected IKE Keep-alive interval is configured using the testvar
    'ikeKeepAlive'. It defaults to 20 seconds based on the default recommendation
    in RFC 3948.

    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 3947 "Negotiation of NAT-Traversal in the IKE"

    https://tools.ietf.org/html/rfc3947

    IETF RFC 3948 "UDP Encapsulation of IPsec ESP Packets"

    https://tools.ietf.org/html/rfc3948

Test	Name	Synopsis
`Verify gateway sends NAT-T Keep-alives in responder mode`	`ike_natt_11`	Verify gateway sends NAT-T Keep-alives in responder mode



    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate Main Mode
    step 4. Use NAT-T detection payload that indicates NAT in both directions
    step 5. Verify Main Mode exchange completes
    step 6. Initiate Quick Mode
    step 7. Verify Quick Mode exchange completes
    step 8. Verify traffic can be sent over the tunnel in both directions
    step 9. Verify IKE Keep-alive packets are sent every ikeKeepAlive seconds

    NOTE: The expected IKE Keep-alive interval is configured using the testvar
    'ikeKeepAlive'. It defaults to 20 seconds based on the default recommendation
    in RFC 3948.

    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 3947 "Negotiation of NAT-Traversal in the IKE"

    https://tools.ietf.org/html/rfc3947

    IETF RFC 3948 "UDP Encapsulation of IPsec ESP Packets"

    https://tools.ietf.org/html/rfc3948

Test	Name	Synopsis
`When floating NAT-T header is used, IKE responses are sent to source port`	`ike_natt_20`	When floating NAT-T header is used, IKE responses are sent to source port



    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate Main Mode and Quick Mode
    step 4. Include NAT-T Vendor ID and NAT-D payloads that indicate NAT
    step 5. Once NAT-T is negotiated switch IKE packets to new UDP source port
    step 6. Verify IKE responses are sent back to UDP source port
    step 7. Once tunnel is established, verify tunnel encapsulation is UDP
    step 8. Initiate traffic from LAN over tunnel
    step 9. Verify ESP traffic is using correct UDP encapsulation based
            on the configured version of NAT-T


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 3947 "Negotiation of NAT-Traversal in the IKE"

    https://tools.ietf.org/html/rfc3947

    IETF RFC 3948 "UDP Encapsulation of IPsec ESP Packets"

    https://tools.ietf.org/html/rfc3948

Test	Name	Synopsis
`Allow IKE negotiations to begin on port 4500`	`ike_natt_30`	Allow IKE negotiations to begin on port 4500



    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate Main Mode using UDP source port 4500 and UDP destination port 4500
    step 4. Verify Main Mode exchange completes
    step 5. Include NAT-T Vendor ID and NAT-D payloads that indicate NAT
    step 6. Once tunnel is established, verify tunnel encapsulation is UDP
    step 7. Initiate traffic from LAN over tunnel
    step 8. Verify ESP traffic is using correct UDP encapsulation based
             on the configured version of NAT-T

    NOTE: The test can only be run if the NAT-T version is greater draft-00.
    Draft-00 only allowed the original IKE port of 500.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 3947 "Negotiation of NAT-Traversal in the IKE"

    https://tools.ietf.org/html/rfc3947

    IETF RFC 3948 "UDP Encapsulation of IPsec ESP Packets"

    https://tools.ietf.org/html/rfc3948

Test	Name	Synopsis
`No UDP encapsulation when NAT not detected in initiator mode`	`ike_natt_40`	No UDP encapsulation when NAT not detected in initiator mode



    step 1. Delete all existing phase 1 and phase 2 SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Send ICMP Echo Request from the LAN that matches the tunnel destination
    step 4. Wait up to 120 seconds for tunnel to be established
    step 5. Include NAT-T Vendor ID and matching NAT-D payloads that
            indicate NAT is not present
    step 6. Once tunnel is established, verify tunnel encapsulation is
            tunnel and not UDP encapsulated
    step 7. Initiate traffic from LAN over tunnel
    step 8. Verify ESP traffic is using native ESP encapsulation

    NOTE: When NAT is not detected based on the NAT-D payloads,
    UDP encapsulation should not be used.

    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 3947 "Negotiation of NAT-Traversal in the IKE"

    https://tools.ietf.org/html/rfc3947

    IETF RFC 3948 "UDP Encapsulation of IPsec ESP Packets"

    https://tools.ietf.org/html/rfc3948

Test	Name	Synopsis
`No UDP encapsulation when NAT not detected in responder mode`	`ike_natt_41`	No UDP encapsulation when NAT not detected in responder mode



    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate Main Mode with NAT-T VID
    step 4. Use matching NAT-D payloads so that no NAT is detected
    step 5. Initiate Quick Mode
    step 6. Verify Quick Mode exchange completes
    step 7. Once tunnel is established, verify tunnel encapsulation
    step 8. Initiate traffic from LAN over tunnel
    step 9. Verify ESP traffic is using native ESP encapsulation
            instead of UDP encapsulation

    NOTE: When NAT is not detected based on the NAT-D payloads,
    UDP encapsulation should not be used.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 3947 "Negotiation of NAT-Traversal in the IKE"

    https://tools.ietf.org/html/rfc3947

    IETF RFC 3948 "UDP Encapsulation of IPsec ESP Packets"

    https://tools.ietf.org/html/rfc3948