Bug 1048702
| Summary: | [TAHI][IKEv2] libreswan doesn't retrans IKE_SA_INIT requests after timeout | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Hangbin Liu <haliu> | ||||
| Component: | libreswan | Assignee: | Paul Wouters <pwouters> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | BaseOS QE Security Team <qe-baseos-security> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 7.0 | CC: | arubin, haliu, lxin | ||||
| Target Milestone: | rc | ||||||
| Target Release: | 7.0 | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2014-09-11 09:09:46 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: | 1049095 | ||||||
| Attachments: |
|
||||||
Are you sure this is not a false positive? I dont believe openswan and libreswan have changed in this aspect. Although the standard retransmit timeout is 20s, 40s, 40s, which is way too slow and I will set it to be at least 1s. The test case does not include any pluto log file. Can you run the test with plutostderrlog=/tmp/pluto.log and attach the log to this bug? Created attachment 846992 [details]
pluto.log
added connection description "ikev2" "ikev2" #1: initiating v2 parent SA "ikev2" #1: transition from state STATE_IKEv2_START to state STATE_PARENT_I1 "ikev2" #1: STATE_PARENT_I1: sent v2I1, expected v2R1 shutting down forgetting secrets "ikev2": deleting connection "ikev2" #1: deleting state (STATE_PARENT_I1) I'm pretty sure you shut down pluto wthin 20 seconds If you add plutodebug=all, you will see something like: | sending 820 bytes for ikev2_parent_outI1_common through br0:500 to 10.2.3.4:500 (using #32) [...] | deleting event for #32 | inserting event EVENT_v2_RETRANSMIT, timeout in 10 seconds for #32 [..] | next event EVENT_v2_RETRANSMIT in 10 seconds for #32 | | next event EVENT_v2_RETRANSMIT in 0 seconds for #32 | *time to handle event | handling event EVENT_v2_RETRANSMIT | event after this is EVENT_PENDING_DDNS in 25 seconds | processing connection init | handling event EVENT_RETRANSMIT for 10.2.3.4 "init" #32 | sending 820 bytes for EVENT_v2_RETRANSMIT through br0:500 to 10.2.3.4:500 (using #32) (In reply to Paul Wouters from comment #4) > I'm pretty sure you shut down pluto wthin 20 seconds > Yes, after looking into the source script, I found the test's default retransmit time is 16s. After change the time to 41s, this test passed. So I want to know whether there is a standard or not? If no, then I can extend the testing time. or I will set the default to the standard time. Thanks Hangbin Liu BTW, Test IKEv2.EN.I.1.1.2.3: Retransmission of IKE_AUTH request passed with default 16s There is no standard for rekey times, and when I went to the IETF IPsec mailing list to ask about clarifying this in rfc5996bis they said they prefer not to and that it is a local policy. Libreswan will go to resend time scale of around the 1 second in version 3.9, so once we get there (or backport that patch) this test should succeed without needing the modification. We just ran out of time to get it into 3.8 that is getting released today. This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request. The comment above is incorrect. The correct version is bellow. I'm sorry for any inconvenience. --------------------------------------------------------------- This request was NOT resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you need to escalate this bug. I'm confused about this as well. AFAIK, this is not a bug. And rekey timing will be made more aggressive in an upcoming version (now scheduled for 3.11) hangbin: I think this should be closed as "not a bug" ? (In reply to Paul Wouters from comment #11) > hangbin: I think this should be closed as "not a bug" ? Yes, sorry for the late response. |
Description of problem: libreswan doesn't retrans IKE_SA_INIT requests after timeout Version-Release number of selected component (if applicable): 3.10.0-61.el7.x86_64 libreswan-3.6-2.el7.x86_64 How reproducible: Steps to Reproduce: NUT TN1 (End-Node) (End-Node) | | |------------------->| IKE_SA_INIT request (HDR, SAi1, KEi, Ni) | | (Judgement #1) | | | * wait for the event of a timeout | | |------------------->| IKE_SA_INIT request (HDR, SAi1, KEi, Ni) | | (Judgement #2) | | V V N: USE_TRANSPORT_MODE Part A: (BASIC) 1. NUT starts to negotiate with TN1 by sending IKE_SA_INIT request. 2. Observe the messages transmitted on Link A. 3. TN1 waits for the event of a timeout on NUT. 4. Observe the messages transmitted on Link A. Actual results: libreswan doesn't retrans IKE_SA_INIT requests after timeout Expected results: libreswan should retrans IKE_SA_INIT requests after timeout Additional info: This is IPv6 Conformance Test for IKEv2 (End Node - Initiator) Test IKEv2.EN.I.1.1.2.1: Retransmission of IKE_SA_INIT request. Openswan have passed this test on RHEL6.5 2.6.32-427.el6.x86_64 openswan-2.6.32-27.el6.x86_64 But libreswan failed on RHEL 7