From: Anthony DeRossi <hidden> Date: 2020-11-03 03:00:17
This fixes a regression where valid selectors are incorrectly skipped
when xfrm_state_find is called with a non-matching address family (e.g.
when using IPv6-in-IPv4 ESP in transport mode).
The state's address family is matched against the template's family
(encap_family) in xfrm_state_find before checking the selector in
xfrm_state_look_at. The template's family should also be used for
selector matching, otherwise valid selectors may be skipped.
Fixes: e94ee171349d ("xfrm: Use correct address family in xfrm_state_find")
Signed-off-by: Anthony DeRossi <redacted>
---
net/xfrm/xfrm_state.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Herbert Xu <herbert@gondor.apana.org.au> Date: 2020-11-03 12:05:24
On Mon, Nov 02, 2020 at 06:32:19PM -0800, Anthony DeRossi wrote:
This fixes a regression where valid selectors are incorrectly skipped
when xfrm_state_find is called with a non-matching address family (e.g.
when using IPv6-in-IPv4 ESP in transport mode).
The state's address family is matched against the template's family
(encap_family) in xfrm_state_find before checking the selector in
xfrm_state_look_at. The template's family should also be used for
selector matching, otherwise valid selectors may be skipped.
Fixes: e94ee171349d ("xfrm: Use correct address family in xfrm_state_find")
Signed-off-by: Anthony DeRossi <redacted>
---
net/xfrm/xfrm_state.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Herbert Xu <herbert@gondor.apana.org.au> Date: 2020-11-03 12:08:45
On Mon, Nov 02, 2020 at 06:32:19PM -0800, Anthony DeRossi wrote:
This fixes a regression where valid selectors are incorrectly skipped
when xfrm_state_find is called with a non-matching address family (e.g.
when using IPv6-in-IPv4 ESP in transport mode).
From: Anthony DeRossi <hidden> Date: 2020-11-03 15:04:04
On Tue, Nov 3, 2020 at 4:05 AM Herbert Xu [off-list ref] wrote:
On Mon, Nov 02, 2020 at 06:32:19PM -0800, Anthony DeRossi wrote:
quoted
This fixes a regression where valid selectors are incorrectly skipped
when xfrm_state_find is called with a non-matching address family (e.g.
when using IPv6-in-IPv4 ESP in transport mode).
The state's address family is matched against the template's family
(encap_family) in xfrm_state_find before checking the selector in
xfrm_state_look_at. The template's family should also be used for
selector matching, otherwise valid selectors may be skipped.
Fixes: e94ee171349d ("xfrm: Use correct address family in xfrm_state_find")
Signed-off-by: Anthony DeRossi <redacted>
---
net/xfrm/xfrm_state.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Your patch reintroduces the same bug that my patch was trying to
fix, namely that when you do the comparison on flow you must use
the original family and not some other value.
My mistake, I misunderstood the original bug.
Anthony
From: Anthony DeRossi <hidden> Date: 2020-11-03 15:17:24
On Tue, Nov 3, 2020 at 4:08 AM Herbert Xu [off-list ref] wrote:
On Mon, Nov 02, 2020 at 06:32:19PM -0800, Anthony DeRossi wrote:
quoted
This fixes a regression where valid selectors are incorrectly skipped
when xfrm_state_find is called with a non-matching address family (e.g.
when using IPv6-in-IPv4 ESP in transport mode).
Why are we even allowing v6-over-v4 in transport mode? Isn't that
the whole point of BEET mode?
I'm not sure. This is the outgoing policy that strongSwan creates for
an IPv6-in-IPv4 tunnel when compression is enabled:
src fd02::/16 dst fd02::2/128
dir out priority 326271 ptype main
tmpl src 10.0.0.8 dst 192.168.1.231
proto comp spi 0x0000d00e reqid 1 mode tunnel
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp spi 0xc543e950 reqid 1 mode transport
After your patch, outgoing IPv6 packets fail to match the associated state:
src 10.0.0.8 dst 192.168.1.231
proto esp spi 0xc543e950 reqid 1 mode transport
replay-window 0
auth-trunc hmac(sha256)
0x143b570f59b23eaa560905f19a922451c6dfa5694ba2e45e1b065bb1863421aa 128
enc cbc(aes) 0x526ed144ca087125ce30e36c8f20d972
encap type espinudp sport 4501 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
sel src 0.0.0.0/0 dst 0.0.0.0/0
Is this an invalid configuration?
Anthony