Bug 1373280
Summary: | RFE: libreswan support for replay-window size | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Paul Wouters <pwouters> |
Component: | libreswan | Assignee: | Paul Wouters <pwouters> |
Status: | CLOSED ERRATA | QA Contact: | Ondrej Moriš <omoris> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.4 | CC: | atragler, omoris, pwouters |
Target Milestone: | rc | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-08-01 12:31:06 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1411853, 1428409 |
Description
Paul Wouters
2016-09-05 17:42:26 UTC
This feature should come in via the rebase to 3.18+ Hi Paul, could you please give us a hint where to verify that the respective size of the IPsec SA replay window protection has been set? Please ignore the above... Note: #ip xfrm state (The following is a cut&paste one of the tunnel status) src X.X.65.79 dst X.X.65.80 proto esp spi 0x65ed196b reqid 16389 mode transport replay-window 32 auth-trunc hmac(sha1) 0xff7557e7bb4e18a27ca99eb9a0ddb60341f34bcb 96 enc cbc(aes) 0xe2a223e936f54a8303635a64c24a18bc sel src X.X.65.79/32 dst X.X.65.80/32 Unfortunately, if you set the replay-window > 32, then it will not show up properly in the ip xfrm state, as that output will use the "old api" that only allows up to 32, and does not display the "new api" that is used for > 32. So if you configure replay-window=64, it will show up as replay-window 0 in the xfrm output. It's a kernel bug. The old api being the struct xfrm_usersa_info.replay_window option, and the new api being the struct xfrm_replay_state_esn.replay_window option. Successfully verified on all supported architectures: replay-window 0 --------------- src 10.16.70.81 dst 10.16.46.45 proto esp spi 0x96a680e3 reqid 16389 mode transport replay-window 0 aead rfc4106(gcm(aes)) 0x69a12f3761f84dda78e9663cf493e2692e5e909cf6ec87fce4da2a526b5cf34f7557f6f3 128 anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000 sel src 10.16.70.81/32 dst 10.16.46.45/32 src 10.16.46.45 dst 10.16.70.81 proto esp spi 0xea134bb4 reqid 16389 mode transport replay-window 0 aead rfc4106(gcm(aes)) 0x081266363bb74bcb18a75d687b10eba780afa38eeb74b66486b588624dfff748983d83c6 128 anti-replay context: seq 0x0, oseq 0xa, bitmap 0x00000000 sel src 10.16.46.45/32 dst 10.16.70.81/32 replay-window 8 --------------- src 10.16.70.81 dst 10.16.46.45 proto esp spi 0x9268410e reqid 16389 mode transport replay-window 8 aead rfc4106(gcm(aes)) 0x70067bd6b770f9264a8270ece8eada2db8682be4a5688b1a1032e490523b77107d8563b7 128 anti-replay context: seq 0xa, oseq 0x0, bitmap 0x000003ff sel src 10.16.70.81/32 dst 10.16.46.45/32 src 10.16.46.45 dst 10.16.70.81 proto esp spi 0x54f75f1e reqid 16389 mode transport replay-window 8 aead rfc4106(gcm(aes)) 0xab4ea8e990ab65a9d757575fc7c0258b0c7482953e8d9930813500f212b9f2fc1f4ff8f5 128 anti-replay context: seq 0x0, oseq 0xa, bitmap 0x00000000 sel src 10.16.46.45/32 dst 10.16.70.81/32 replay-window 64 ---------------- src 10.16.70.81 dst 10.16.46.45 proto esp spi 0x193b75f5 reqid 16389 mode transport replay-window 0 aead rfc4106(gcm(aes)) 0x39f18d8230a6b36e67a58f08267890aa2539c96139ba4b9fd86c72e444a98e7a0b440769 128 anti-replay esn context: seq-hi 0x0, seq 0xa, oseq-hi 0x0, oseq 0x0 replay_window 64, bitmap-length 2 00000000 000003ff sel src 10.16.70.81/32 dst 10.16.46.45/32 src 10.16.46.45 dst 10.16.70.81 proto esp spi 0xc82cf99e reqid 16389 mode transport replay-window 0 aead rfc4106(gcm(aes)) 0x31575e2cf94659a9a96dfdc9af91fdc5f124ea67be2c95ae4f666e73ee8eaab934c8d830 128 anti-replay esn context: seq-hi 0x0, seq 0x0, oseq-hi 0x0, oseq 0xa replay_window 64, bitmap-length 2 00000000 00000000 replay-window unspecified [default] ----------------------------------- src 10.34.88.24 dst 10.34.88.46 proto esp spi 0xc0fc97b4 reqid 16389 mode transport replay-window 32 aead rfc4106(gcm(aes)) 0x64cbd07942fb6d4fbc61ca2cd6b1eb3fb85e8073078e2b5260b478d66d4660ad032f53cf 128 anti-replay context: seq 0x14, oseq 0x0, bitmap 0x000fffff sel src 10.34.88.24/32 dst 10.34.88.46/32 src 10.34.88.46 dst 10.34.88.24 proto esp spi 0x1612e9ce reqid 16389 mode transport replay-window 32 aead rfc4106(gcm(aes)) 0xd5d7909f547e8937a9acd8444ca820643f6927a503f47ffe7d8d7970078dfd559b38267f 128 anti-replay context: seq 0x0, oseq 0x14, bitmap 0x00000000 sel src 10.34.88.46/32 dst 10.34.88.24/32 See TJ#1867005 for more details. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2101 |