Bug 1315732 - Pluto does not handle delete message from responder site in ikev1
Pluto does not handle delete message from responder site in ikev1
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libreswan (Show other bugs)
6.8
All Linux
medium Severity medium
: rc
: 6.9
Assigned To: Paul Wouters
BaseOS QE Security Team
:
Depends On: 1219049
Blocks: 1414846 1425546
  Show dependency treegraph
 
Reported: 2016-03-08 08:39 EST by Jaroslav Aster
Modified: 2017-03-24 14:00 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1219049
Environment:
Last Closed: 2017-03-24 14:00:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
IBM Linux Technology Center 146484 None None None 2016-09-19 10:40 EDT

  None (edit)
Description Jaroslav Aster 2016-03-08 08:39:14 EST
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 04:38:13 EST
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 15:21:40 EST
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 14:00:07 EDT
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

Note You need to log in before you can comment on or make changes to this bug.