Bug 1315732

Summary: Pluto does not handle delete message from responder site in ikev1
Product: Red Hat Enterprise Linux 6 Reporter: Jaroslav Aster <jaster>
Component: libreswanAssignee: Paul Wouters <pwouters>
Status: CLOSED WONTFIX QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.8CC: bugproxy, hannsj_uhl, jkachuck, omoris, pwouters
Target Milestone: rc   
Target Release: 6.9   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1219049 Environment:
Last Closed: 2017-03-24 18:00:07 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: 1219049    
Bug Blocks: 1414846, 1425546    

Description Jaroslav Aster 2016-03-08 13:39:14 UTC
The same issue on rhel-6's libreswan.

libreswan-3.15-5.3.el6

+++ This bug was initially created as a clone of Bug #1219049 +++

Description of problem:

Pluto does not handle delete message from Responder site in ikev1 like service ipsec stop or ipsec auto --down CONNECTION.


Version-Release number of selected component (if applicable):

3.10.0-229.ael7b
3.10.0-229.el7


How reproducible:

100%


Steps to Reproduce:

Configuration
-------------

# cat /etc/ipsec.conf
config setup
    protostack=netkey
    plutodebug=all
    nat_traversal=yes
    plutostderrlog=/tmp/pluto.log

conn test
    left=<INITIATOR>
    right=<RESPONDER>
    authby=secret
    phase2=esp
    auto=add
    ikev2=no

# cat /etc/ipsec.secrets 
: PSK "redhat"

Scenario
--------

I:

# service ipsec start
# ipsec auto --status
...
000 "test":   newest ISAKMP SA: #0; newest IPsec SA: #0; 
000  
000 Total IPsec connections: loaded 1, active 0
...


R:

# service ipsec start
# ipsec auto --status
...
000 "test":   newest ISAKMP SA: #0; newest IPsec SA: #0;
000
000 Total IPsec connections: loaded 1, active 0
...

I:

# ipsec auto --up
002 "test" #1: initiating Main Mode
104 "test" #1: STATE_MAIN_I1: initiate
003 "test" #1: received Vendor ID payload [Dead Peer Detection]
003 "test" #1: received Vendor ID payload [FRAGMENTATION]
003 "test" #1: received Vendor ID payload [RFC 3947]
002 "test" #1: enabling possible NAT-traversal with method RFC 3947 (NAT-Traversal)
002 "test" #1: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
106 "test" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "test" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal) sender port 500: no NAT detected
002 "test" #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
108 "test" #1: STATE_MAIN_I3: sent MI3, expecting MR3
002 "test" #1: Main mode peer ID is ID_IPV4_ADDR: '10.16.70.85'
002 "test" #1: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
004 "test" #1: STATE_MAIN_I4: ISAKMP SA established {auth=PRESHARED_KEY cipher=aes_256 integ=sha group=MODP2048}
002 "test" #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+SAREF_TRACK+IKE_FRAG_ALLOW {using isakmp#1 msgid:e1473fad proposal=defaults pfsgroup=OAKLEY_GROUP_MODP2048}
117 "test" #2: STATE_QUICK_I1: initiate
002 "test" #2: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2
004 "test" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0x53c3a750 <0xaa955d4f xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=passive}

# ipsec auto --status
...
000 "test":   newest ISAKMP SA: #1; newest IPsec SA: #2; 
000 "test":   IKE algorithm newest: AES_CBC_256-SHA1-MODP2048
000 "test":   ESP algorithm newest: AES_128-HMAC_SHA1; pfsgroup=<Phase1>
000  
000 Total IPsec connections: loaded 1, active 1
...

R:

# ipsec auto --status
...
000 "test":   newest ISAKMP SA: #1; newest IPsec SA: #2; 
000 "test":   IKE algorithm newest: AES_CBC_256-SHA1-MODP2048
000 "test":   ESP algorithm newest: AES_128-HMAC_SHA1; pfsgroup=<Phase1>
000  
000 Total IPsec connections: loaded 1, active 1
...

# ipsec auto --down test
002 "test": terminating SAs using this connection
002 "test" #2: deleting state (STATE_QUICK_R2)
005 "test" #2: ESP traffic information: in=0B out=0B
002 "test" #1: deleting state (STATE_MAIN_R3)

# ipsec auto --status
...
000 "test":   newest ISAKMP SA: #3; newest IPsec SA: #4; 
000 "test":   IKE algorithm newest: AES_CBC_256-SHA1-MODP2048
000 "test":   ESP algorithm newest: AES_128-HMAC_SHA1; pfsgroup=<Phase1>
000  
000 Total IPsec connections: loaded 1, active 1
...

I:

# ipsec auto --status
...
000 "test":   newest ISAKMP SA: #3; newest IPsec SA: #4; 
000 "test":   IKE algorithm newest: AES_CBC_256-SHA1-MODP2048
000 "test":   ESP algorithm newest: AES_128-HMAC_SHA1; pfsgroup=<Phase1>
000  
000 Total IPsec connections: loaded 1, active 1
...

# service ipsec stop

R:

# service ipsec --status
...
000 "test":   newest ISAKMP SA: #0; newest IPsec SA: #0; 
000  
000 Total IPsec connections: loaded 1, active 0
...

# service ipsec stop


Additional information:

Log are attached.

ipsec auto --down CONNECTION works on INITIATOR site.

If I remove plutostderrlog option from configuration file, connection on RESPONDER is deleted after ipsec auto --down CONNECTION command and on INITIATOR site is active (IPSEC SA).

R:

# ipsec auto --down CONNECTION
# ipsec auto --status
000 "test":   newest ISAKMP SA: #0; newest IPsec SA: #0;
000
000 Total IPsec connections: loaded 1, active 0

I:

000 "test":   newest ISAKMP SA: #0; newest IPsec SA: #2;
000 "test":   ESP algorithm newest: AES_128-HMAC_SHA1; pfsgroup=<Phase1>
000
000 Total IPsec connections: loaded 1, active 1


--- Additional comment from Paul Wouters on 2015-10-07 13:16:39 EDT ---

very strange. It seems to delete the isakmp sa but not the ipsec sa. Definitely a regression we had not noticied before. Present in current upstream git master.

Comment 1 Jaroslav Aster 2016-03-09 09:38:13 UTC
I did test with libreswan-3.15-5.3.el6 and there is a little bit different behaviour. After responder does --down connection, everything on responder's site is removed. On initiator site only ISAKMP is removed. Ipsec SA remains.

Comment 5 Paul Wouters 2017-03-01 20:21:40 UTC
yes, we synced the behaviour, although we are still looking at a better more permanent solution upstream. But it is not urgent because this behaviour has existed for 20 years.

Comment 7 Joseph Kachuck 2017-03-24 18:00:07 UTC
Hello,
RHEL 6 has entered Phase 3. In phase 3 only Critical impact Security Advisories and selected Urgent Priority Bug Fix Advisories will be accepted.
https://access.redhat.com/support/policy/updates/errata

At current this BZ does not meet these requirements. I am closing this BZ as WONTFIX.

Please reopen if this fix is required for RHEL 6. If so please also provide a justification for this fix.

Thank You
Joe Kachuck