A correction, I meant inbound rule, not input rule. Juraj
From: Juraj Linkeš Sent: Thursday, September 9, 2021 10:59 AM To: 'Zachary Leaf' <zachary.l...@arm.com>; 'ne...@graphiant.com' <ne...@graphiant.com> Cc: vpp-dev <vpp-dev@lists.fd.io> Subject: RE: [vpp-dev] IPSec input/output: default action for non-matching traffic Hi Neale, Did you have a chance to look at this? For my part, I'm trying to figure out how to configure VPP with two DPDK interfaces where I would send bidirectional traffic (unencrypted, since the traffic generator in question (T-rex) can't send encrypted traffic yet) and I'd match an input rule in each direction - is this even possible? Thanks, Juraj From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> On Behalf Of Zachary Leaf Sent: Tuesday, August 17, 2021 10:30 AM To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Subject: [vpp-dev] IPSec input/output: default action for non-matching traffic 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20104): https://lists.fd.io/g/vpp-dev/message/20104 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] -=-=-=-=-=-=-=-=-=-=-=-
