1. Vpp-Dev
  2. Topics

Locked All UDP packet being dropped at “ipsec4_input_node” when IPSEC policy configured

Tripathi, VinayX
 

Hi Team,

 

All UDP packet being dropped at “ipsec4_input_node”  if ipsec inbound and outbound policy configured. Not that udp_encp is not enabled.

Where TCP and ICMP has no such issue.

System is treating normal UDP and UDP encapsulated ESP packet in same way. Probably we have to use DST and SRC port of UDP

With compliance of RFC :- 3948.

Used Topology :-

 

PKT-G0 — dut1_eth0 ------ dut1_eth1 ------- dut2_eth0 -------- dut2_eth1 ----- PKT-G1

 

In file : src/vnet/ipsec/ipsec_input.c

      if (PREDICT_TRUE

          (ip0->protocol == IP_PROTOCOL_IPSEC_ESP

           || ip0->protocol == IP_PROTOCOL_UDP))

        {

 

          esp0 = (esp_header_t *) ((u8 *) ip0 + ip4_header_bytes (ip0));

          if (PREDICT_FALSE (ip0->protocol == IP_PROTOCOL_UDP))

            {

              /* FIXME Skip, if not a UDP encapsulated packet */

              esp0 = (esp_header_t *) ((u8 *) esp0 + sizeof (udp_header_t));

            }

 

CFG :

DUT 1

set int ip address dut1_eth0 192.168.3.1/24

set int promiscuous on dut1_eth0

set ip neighbor dut1_eth0 192.168.0.1 11:22:33:44:55:66

set int ip address dut1_eth1 30.30.30.1/30

set int promiscuous on dut1_eth1

set ip neighbor dut1_eth1 30.30.30.2 11:22:33:44:55:66

ipsec spd add 1

set interface ipsec spd dut1_eth0 1

set interface ipsec spd dut1_eth1 1

 

ipsec sa add 0 spi 0 esp crypto-alg aes-gcm-128 crypto-key 31323334353637383930313233343536 salt 0x31323334

ipsec sa add 1 spi 1 esp crypto-alg aes-gcm-128 crypto-key 31323334353637383930313233343536 salt 0x31323334

ipsec policy add spd 1 priority 10 outbound action protect sa 1 local-ip-range 10.64.0.0 - 10.64.0.5 remote-ip-range 20.64.0.0 - 20.64.0.5

ipsec policy add spd 1 priority 10 outbound action bypass local-ip-range 20.64.0.0 - 20.64.0.5 remote-ip-range 10.64.0.0 - 10.64.0.5

ipsec policy add spd 1 priority 10 inbound action protect sa 0 local-ip-range 10.64.0.0 - 10.64.0.5 remote-ip-range 20.64.0.0 - 20.64.0.5

ip route add 10.64.0.0/30 via 192.168.0.1 dut1_eth0

ip route add 20.64.0.0/30 via 30.30.30.2 dut1_eth1

 

 

Proposed solution :  “ipsec4_input_node”   node can compare ingress packet with sa->udp_hdr.dst_port and ipsec_sa_is_set_UDP_ENCAP (sa0) at first level of check.

That will help in distinguish normal UDP and UDP encapsulated ESP packet. At this stage , SA will be fetch from protected inbound policy.  

 

 

--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Varun Tewari
 

Thank you for bringing this to the fore.
I am noticing something interesting along the same lines as well during my investigation.
I am using strongswan as the initiator and VPP Ikev2 as the responder.

My observations are:
1. Strongswan initiator forceencap=yes and VPP responder ikev2 profile set udp-encap, my tunnels do not come up. Ike gets established but CHILD_SA fails.
2. Strongswan initiator forceencap=no and VPP responder ikev2 profile set udp-encap, my tunnels come up. Traffic drops with ESP_DECRYPT_ERROR_TUN_NO_PROTO (all traffic)
3. Strongswan initiator forceencap=yes and VPP responder udp-encap not set in profile, my tunnels do come up and traffic flows.

Let me know as well if these are expected observations.

1 - 2 of 2