Re: [vpp-dev] IPSec input/output: default action for non-matching traffic
Hi Andrew, The tests updated as part of this patch[1] are related to the IPSec outbound side "flow cache" i.e. test/test_ipsec_spd_flow_cache.py (see commit[2]). This is really testing the behaviour of the flow cache, rather than this drop by default behaviour described here. These tests just happened to highlight this specific behaviour, rather than be designed specifically to test that. If we wanted to add some tests for packets getting dropped by default, which is probably a good idea, I'd propose to add something in one of the test/test_ipsec_xyz.py files or create a new test suite to test both ways (inbound/outbound). I'm not working on VPP at the moment but I will find the time to add these to the patch hopefully soon. Best, Zach 1: https://gerrit.fd.io/r/c/vpp/+/34252 2: https://gerrit.fd.io/r/gitweb?p=vpp.git;a=commit;h=6d7dfcbfa4bc05f1308fc677f19ade44ea699da1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20798): https://lists.fd.io/g/vpp-dev/message/20798 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] IPSec input/output: default action for non-matching traffic
Zach, Neale, Just a thought from the “make test” PoV: If understand this email thread well, this change adds a behavior, relying on which can create security implications in case this new behavior gets broken - so you think you could add a few negative tests as well ? (I.e. that the packets indeed *are* dropped when they should be). If I am reading the tests right, they seem to be only verifying that the packets are passing… (apologies in advance if this is a misunderstanding) Thoughts ? --a > On 27 Jan 2022, at 09:51, Zachary Leaf wrote: > > > Hi Neale, > > Please see https://gerrit.fd.io/r/c/vpp/+/34252 for the patch for this. Would > appreciate a review when you get the chance so Juraj can start adding the > CSIT tests required for the inbound side IPSec flow cache > (https://gerrit.fd.io/r/c/vpp/+/32903). > > Best, > > Zach > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20797): https://lists.fd.io/g/vpp-dev/message/20797 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] IPSec input/output: default action for non-matching traffic
Hi Neale, Please see https://gerrit.fd.io/r/c/vpp/+/34252 for the patch for this. Would appreciate a review when you get the chance so Juraj can start adding the CSIT tests required for the inbound side IPSec flow cache ( https://gerrit.fd.io/r/c/vpp/+/32903 ). Best, Zach -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20796): https://lists.fd.io/g/vpp-dev/message/20796 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] IPSec input/output: default action for non-matching traffic
Hi Zach, Apologies for the late reply and thank you for the considered analysis. ..snip.. 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. No reason I know of. Please patch as you suggest. Regards, neale 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 (#20113): https://lists.fd.io/g/vpp-dev/message/20113 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] IPSec input/output: default action for non-matching traffic
A correction, I meant inbound rule, not input rule. Juraj From: Juraj Linkeš Sent: Thursday, September 9, 2021 10:59 AM To: 'Zachary Leaf' ; 'ne...@graphiant.com' Cc: vpp-dev 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> 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 (0x03e8) 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] -=-=-=-=-=-=-=-=-=-=-=-
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 On Behalf Of Zachary Leaf Sent: Tuesday, August 17, 2021 10:30 AM To: 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 (0x03e8) 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 (#20103): https://lists.fd.io/g/vpp-dev/message/20103 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] -=-=-=-=-=-=-=-=-=-=-=-
[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 (0x03e8) 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
