Bug 1322395

Summary: libreswan Ikev2 implementation does not correctly process traffic selectors narrowed to TCP
Product: Red Hat Enterprise Linux 6 Reporter: Jaroslav Aster <jaster>
Component: libreswanAssignee: Paul Wouters <pwouters>
Status: CLOSED NOTABUG QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.8   
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1127605 Environment:
Last Closed: 2016-07-04 08:23:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Jaroslav Aster 2016-03-30 12:24:21 UTC 
+++ This bug was initially created as a clone of Bug #1127605 +++

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

Description of problem:
openswan Ikev2 implementation does not correctly process traffic selectors narrowed to TCP

Version-Release number of selected component (if applicable):
libreswan-3.8-6.el7_0

How reproducible:
Always

Steps to Reproduce:
1. Configure libreswan like following:
/etc/ipsec.conf:

INITIATOR:

config setup
    protostack=netkey
    plutodebug=all
    nat_traversal=yes
    plutostderrlog=/var/log/test.log

conn test
    left=$INITIATOR
    right=$RESPONDER
    authby=secret
    phase2=esp
    auto=add
    ikev2=insist


RESPONDER:

config setup
    protostack=netkey
    plutodebug=all
    nat_traversal=yes
    plutostderrlog=/var/log/test.log

conn test
    left=$INITIATOR
    right=$RESPONDER
    authby=secret
    phase2=esp
    auto=add
    ikev2=insist
    leftprotoport=tcp
    rightprotoport=tcp
2. both sides: service ipsec (re)start; initiator: ipsec auto --up test
3. Check ISAKMP, IPSEC SAs (should be alive): ipsec auto --status
  
Actual results:
133 "test" #1: STATE_PARENT_I1: initiate
133 "test" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
134 "test" #2: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=aes_128 integ=sha1_96 prf=oakley_sha group=modp2048}
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 20s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 40s for response
031 "test" #2: max number of retransmissions (20) reached STATE_PARENT_I2.  Possible authentication failure: no acceptable response to our first encrypted message
000 "test" #2: starting keying attempt 1 of an unlimited number, but releasing whack
133 "test" #11: STATE_PARENT_I1: initiate, replacing #1
133 "test" #11: STATE_PARENT_I1: sent v2I1, expected v2R1
:: [   PASS   ] :: Running 'ipsec auto --up test' (Expected 0, got 0)
whack: is Pluto running?  connect() for "/var/run/pluto/pluto.ctl" failed (111 Connection refused)
:: [   PASS   ] :: Running 'ipsec auto --status' (Expected 0, got 0)
:: [   PASS   ] :: Running 'ip xfrm state' (Expected 0, got 0)
whack: is Pluto running?  connect() for "/var/run/pluto/pluto.ctl" failed (111 Connection refused)
:: [   FAIL   ] :: ISAKMP SA should be alive (Expected 0, got 1)
whack: is Pluto running?  connect() for "/var/run/pluto/pluto.ctl" failed (111 Connection refused)


Expected results:


Additional info:

--- Additional comment from Paul Wouters on 2014-10-24 00:13:54 EDT ---

the configuration is missing narrowing=yes in the connection configuration. Please try again?

See also the 7 or so narrowing test case configurations we have at 

https://github.com/libreswan/libreswan/tree/master/testing/pluto

--- Additional comment from Aleš Mareček on 2014-12-05 08:26:30 EST ---

Same as there: https://bugzilla.redhat.com/show_bug.cgi?id=1125913#c4

--- Additional comment from Paul Wouters on 2015-01-28 12:25:44 EST ---

Our test case for this passes: https://github.com/libreswan/libreswan/tree/master/testing/pluto/ikev2-allow-narrow-06

the responder also needs narrowing=yes in its configuration.

--- Additional comment from Aleš Mareček on 2015-02-08 12:03:48 EST ---

narrowing=yes didn't help.

--- Additional comment from Aleš Mareček on 2015-02-08 12:04:07 EST ---



--- Additional comment from Paul Wouters on 2015-02-26 23:25:44 EST ---

can you provide logs and config of your latest attempt?

--- Additional comment from Paul Wouters on 2016-01-21 11:26:07 EST ---

ping? Can we either close this bug or confirm it? To confirm it, I need to see the configuration files used.

--- Additional comment from Jaroslav Aster on 2016-03-23 13:36:03 EDT ---

Hi Paul,

it still fails. Tested on libreswan-3.15-5.el7_1. Openswan, on the same test, passes.

Server:

config setup
    protostack=netkey
    plutodebug=all
    nat_traversal=yes
    plutostderrlog=/var/log/pluto.log

conn test
    type=tunnel
    left=<CLIENT_IP>
    right=<SERVER_IP>
    authby=secret
    phase2=esp
    auto=add
    ikev2=insist

Client:

config setup
    protostack=netkey
    plutodebug=all
    nat_traversal=yes
    plutostderrlog=/var/log/pluto.log

conn test
    type=tunnel
    left=<CLIENT_IP>
    right=<SERVER_IP>
    authby=secret
    phase2=esp
    auto=add
    ikev2=insist
    leftprotoport=tcp
    rightprotoport=tcp

S:

# service ipsec start

C:

# service ipsec start

# ipsec auto --up test
002 "test" #1: initiating v2 parent SA
133 "test" #1: STATE_PARENT_I1: initiate
133 "test" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
134 "test" #2: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=aes_gcm_16_256 integ=n/a prf=sha group=MODP2048}
003 "test" #1: missing payload(s) (ISAKMP_NEXT_v2SK). Message dropped.
207 "test" #1: STATE_PARENT_I2: v2N_INVALID_SYNTAX
003 "test" #1: EXPECTATION FAILED at /builddir/build/BUILD/libreswan-3.15/programs/pluto/ikev2.c:1831: st != NULL && st->st_event != NULL && st->st_event->ev_type == EVENT_v2_RETRANSMIT
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 500ms for response
003 "test" #1: missing payload(s) (ISAKMP_NEXT_v2SK). Message dropped.
207 "test" #1: STATE_PARENT_I2: v2N_INVALID_SYNTAX
003 "test" #1: EXPECTATION FAILED at /builddir/build/BUILD/libreswan-3.15/programs/pluto/ikev2.c:1831: st != NULL && st->st_event != NULL && st->st_event->ev_type == EVENT_v2_RETRANSMIT
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 1000ms for response
003 "test" #1: missing payload(s) (ISAKMP_NEXT_v2SK). Message dropped.
207 "test" #1: STATE_PARENT_I2: v2N_INVALID_SYNTAX
003 "test" #1: EXPECTATION FAILED at /builddir/build/BUILD/libreswan-3.15/programs/pluto/ikev2.c:1831: st != NULL && st->st_event != NULL && st->st_event->ev_type == EVENT_v2_RETRANSMIT
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 2000ms for response
003 "test" #1: missing payload(s) (ISAKMP_NEXT_v2SK). Message dropped.
207 "test" #1: STATE_PARENT_I2: v2N_INVALID_SYNTAX
003 "test" #1: EXPECTATION FAILED at /builddir/build/BUILD/libreswan-3.15/programs/pluto/ikev2.c:1831: st != NULL && st->st_event != NULL && st->st_event->ev_type == EVENT_v2_RETRANSMIT
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 4000ms for response
003 "test" #1: missing payload(s) (ISAKMP_NEXT_v2SK). Message dropped.
207 "test" #1: STATE_PARENT_I2: v2N_INVALID_SYNTAX
003 "test" #1: EXPECTATION FAILED at /builddir/build/BUILD/libreswan-3.15/programs/pluto/ikev2.c:1831: st != NULL && st->st_event != NULL && st->st_event->ev_type == EVENT_v2_RETRANSMIT
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 8000ms for response
003 "test" #1: missing payload(s) (ISAKMP_NEXT_v2SK). Message dropped.
207 "test" #1: STATE_PARENT_I2: v2N_INVALID_SYNTAX
003 "test" #1: EXPECTATION FAILED at /builddir/build/BUILD/libreswan-3.15/programs/pluto/ikev2.c:1831: st != NULL && st->st_event != NULL && st->st_event->ev_type == EVENT_v2_RETRANSMIT
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 16000ms for response
003 "test" #1: missing payload(s) (ISAKMP_NEXT_v2SK). Message dropped.
207 "test" #1: STATE_PARENT_I2: v2N_INVALID_SYNTAX
003 "test" #1: EXPECTATION FAILED at /builddir/build/BUILD/libreswan-3.15/programs/pluto/ikev2.c:1831: st != NULL && st->st_event != NULL && st->st_event->ev_type == EVENT_v2_RETRANSMIT
^C

--- Additional comment from Jaroslav Aster on 2016-03-30 08:20:39 EDT ---

There is no change with adding option narrowing=yes on both site - server, client, but if I add 

leftprotoport=tcp
rightprotoport=tcp

to the server conf instead of client conf, then it works.
Comment 1 Jaroslav Aster 2016-03-30 12:28:16 UTC 
I forgot. Tested on libreswan-3.15-5.3.el6.
Comment 2 Paul Wouters 2016-07-04 08:23:48 UTC 
yes, the specification allows one to NARROW a request, not to WIDEN a request.

So the client sends 0/0 and the server narrows it to tcp. You cannot do it the other way around.

See: https://tools.ietf.org/html/rfc7296#section-2.9