Hi Neale/all, I've noticed an inconsistency between the default behaviour for non-matching packets in the ipsec-input and ipsec-output nodes. I'm not sure if this intended or not.
The summary is: - For ipsec-output, any non-matching packets are dropped by default with the same mechanism as per a matching DISCARD rule - For ipsec-input, any non-matching packets are passed to the next node as if they matched a BYPASS rule Below are some packet traces that show this behaviour. The setup is 2x interfaces configured as ip neighbors, with an SPD bound to each. Traffic entering an interface is routed through the other interface and vice-versa (see attached ipsec-default-drop.txt for full script). When SPD contains only matching INBOUND BYPASS rules: 00:00:07:340457: dpdk-input 00:00:07:340523: ethernet-input 00:00:07:340566: ip4-input-no-checksum 00:00:07:340601: ipsec4-input-feature IPSEC_ESP: sa_id 0 spd 2 policy 1 spi 1000 (0x000003e8) seq 3 <----- MATCHED INBOUND RULE (policy 1) 00:00:07:340642: ip4-lookup 00:00:07:340667: ip4-rewrite 00:00:07:340680: ipsec4-output-feature spd 1 policy -1 <----- DID NOT MATCH ANY RULES (policy -1) 00:00:07:340693: error-drop <----- PACKET DROPPED 00:00:07:340707: drop When SPD contains only matching OUTBOUND BYPASS rules: 00:00:11:759484: dpdk-input 00:00:11:759570: ethernet-input 00:00:11:759624: ip4-input-no-checksum 00:00:11:759654: ipsec4-input-feature UDP: sa_id 4294967295 spd 2 policy -1 spi 612811835 (0x2486c43b) seq 748568697 <---- DID NOT MATCH (policy -1) 00:00:11:759689: ip4-lookup <----- PACKET *NOT* DROPPED, PASSED ON AS NORMAL 00:00:11:759721: ip4-rewrite 00:00:11:759733: ipsec4-output-feature spd 1 policy 1 <---- MATCHED OUTBOUND RULE 00:00:11:759774: TenGigabitEthernet7/0/0-output 00:00:11:759801: TenGigabitEthernet7/0/0-tx Looking at the code in ipsec_output.c, we can see that for non-matching packets, we call next_node_index = im->error_drop_node_index to drop the packet. In ipsec_input.c, we only increment the counter ipsec_unprocessed += 1 and we move to the next packet as per a matching BYPASS rule. From what I can tell, this is the same for both ipv4/ipv6 traffic. Looking at the IPSec RFC4301 [1], it seems to suggest that the default action for both non-matching inbound/output packets should be DISCARD. e.g. “Since the SPD-I is just a part of the SPD, if a packet that is looked up in the SPD-I cannot be matched to an entry there, then the packet MUST be discarded” [2] " ... the SPD (or associated caches) MUST be consulted during the processing of all traffic that crosses the IPsec protection boundary, including IPsec management traffic. If no policy is found in the SPD that matches a packet (for either inbound or outbound traffic), the packet MUST be discarded." [3] "Every SPD SHOULD have a nominal, final entry that catches anything that is otherwise unmatched, and discards it. This ensures that non-IPsec-protected traffic that arrives and does not match any SPD-I entry will be discarded." [4] In the section 5.2. Processing Inbound IP Traffic (unprotected-to-protected) [4], there is also a diagram that seems to support this. Is there a reason that the input side is setup like this? Unless there is a good reason for allowing inbound traffic by default, I would propose to patch the ipsec-input node to align with ipsec-output and drop traffic by default. Best, Zach [1]: https://datatracker.ietf.org/doc/html/rfc4301 [2]: https://datatracker.ietf.org/doc/html/rfc4301#section-4.4.1 [3]: https://datatracker.ietf.org/doc/html/rfc4301#section-5 [4]: https://datatracker.ietf.org/doc/html/rfc4301#section-5.2
set int ip address TenGigabitEthernet7/0/0 10.10.10.1/24 set int ip address TenGigabitEthernet7/0/1 20.20.20.1/24 set int state TenGigabitEthernet7/0/0 up set int state TenGigabitEthernet7/0/1 up set interface promiscuous on TenGigabitEthernet7/0/0 set interface promiscuous on TenGigabitEthernet7/0/1 set ip neighbor TenGigabitEthernet7/0/0 10.10.10.10 00:00:0A:81:11:22 static count 1 set ip neighbor TenGigabitEthernet7/0/1 20.20.20.20 00:00:0A:81:11:11 static count 1 ipsec spd add 1 set interface ipsec spd TenGigabitEthernet7/0/0 1 ipsec spd add 2 set interface ipsec spd TenGigabitEthernet7/0/1 2 // input rules only - delete this or below ipsec policy add spd 1 priority 1 inbound action bypass remote-ip-range 10.10.10.0 - 10.10.10.255 local-ip-range 20.20.20.0 - 20.20.20.255 ipsec policy add spd 2 priority 1 inbound action bypass remote-ip-range 20.20.20.0 - 20.20.20.255 local-ip-range 10.10.10.0 - 10.10.10.255 // end // output rules only - delete this or above ipsec policy add spd 2 priority 1 outbound action bypass outbound local-ip-range 10.10.10.0 - 10.10.10.255 remote-ip-range 20.20.20.0 - 20.20.20.255 ipsec policy add spd 1 priority 1 outbound action bypass outbound local-ip-range 20.20.20.0 - 20.20.20.255 remote-ip-range 10.10.10.0 - 10.10.10.255 // end
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19975): https://lists.fd.io/g/vpp-dev/message/19975 Mute This Topic: https://lists.fd.io/mt/84943480/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
