[Swan-dev] a pexecpt/??? comment answer :)
Paul Wouters 🔓
paul at nohats.ca
Thu Dec 4 16:49:39 EET 2014
Hi,
At some time, Hugh added the follow pexpect() in ikev1_agg.c:
static stf_status aggr_inI1_outR1_common(struct msg_digest *md,
int authtype)
{
[...]
struct state *st;
struct payload_digest *const sa_pd = md->chain[ISAKMP_NEXT_SA];
struct connection *c = find_host_connection( );
[...]
if (c == NULL) {
[...]
}
/* Set up state */
cur_state = md->st = st = new_state(); /* (caller will reset cur_state) */
st->st_connection = c;
[...]
pexpect(c == st->st_connection); /* ??? how would this have changed? */
c = st->st_connection;
This expect fired in the new testcase netkey-audit-01. I think it is a
false positive and this situations is correct and the passert should be
changed for a comment instead. See below for details (and let me know if
you agree or not)
The test case loads 3 IKE connections between the same host pair, with
aggressive mode, main mode and ikev2. It uses different IDs to avoid
hitting our selection mechanism that will reject the first partial
mismatch (@west-v1-aggr, @west-v1 or @west-v2, etc...)
It then runs up and delete to establish these one after the other, to
confirm that the audit code logs properly for aggressive, main and ikev2
modes.
ipsec auto --up ikev1
ipsec auto --delete ikev1
ipsec auto --up ikev1-aggr
ipsec auto --delete ikev1-aggr
ipsec auto --up ikev2
ipsec auto --down ikev2
Since these will be the same hostpair, some connection switching is
expected to happen.
added connection description "ikev1"
added connection description "ikev1-aggr"
added connection description "ikev2"
listening for IKE messages
[...]
packet from 192.1.2.45:500: received Vendor ID payload [Dead Peer Detection]
packet from 192.1.2.45:500: received Vendor ID payload [FRAGMENTATION]
packet from 192.1.2.45:500: received Vendor ID payload [RFC 3947]
packet from 192.1.2.45:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
packet from 192.1.2.45:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
packet from 192.1.2.45:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
"ikev2" #1: enabling possible NAT-traversal with method RFC 3947 (NAT-Traversal)
"ikev2" #1: responding to Main Mode
Note that I only had ikev2=yes on east, and no ikev2= line for the ikev1
connections, so in theory in the ikev2 one _could_ actually take on the
ikev1 connection, except the IDs won't match up, so it has to switch.
But this is main mode, no ID has been sent yet.
"ikev2" #1: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
"ikev2" #1: STATE_MAIN_R1: sent MR1, expecting MI2
"ikev2" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal) sender port 500: no NAT detected
"ikev2" #1: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
"ikev2" #1: STATE_MAIN_R2: sent MR2, expecting MI3
"ikev2" #1: Main mode peer ID is ID_FQDN: '@west-v1'
"ikev2" #1: switched from "ikev2" to "ikev1"
It properly switched here.
"ikev1" #1: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
"ikev1" #1: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=RSA_SIG cipher=aes_256 integ=sha group=MODP1536}
"ikev1" #1: the peer proposed: 192.0.2.0/24:0/0 -> 192.0.1.0/24:0/0
"ikev1-aggr" #2: responding to Quick Mode proposal {msgid:79ee6768}
"ikev1-aggr" #2: us: 192.0.2.0/24===192.1.2.23<192.1.2.23>[@east-v1]
"ikev1-aggr" #2: them: 192.1.2.45<192.1.2.45>[@west-v1]===192.0.1.0/24
"ikev1-aggr" #2: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
"ikev1-aggr" #2: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
"ikev1-aggr" #2: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
"ikev1-aggr" #2: STATE_QUICK_R2: IPsec SA established tunnel mode {ESP=>0xacbb9b00 <0x8af31c0e xfrm=AES_128-HMAC_SHA1 IPCOMP=>0x00007b03 <0x00006621 NATOA=none NATD=none DPD=passive}
This "switch" is a little more confusing. the ikev1-aggr IDs don't match
up. Why did it say this one came up?
"ikev1" #1: received Delete SA(0xacbb9b00) payload: deleting IPSEC State #2
"ikev1" #1: deleting state #2 (STATE_QUICK_R2)
"ikev1" #1: ESP traffic information: in=0B out=0B
"ikev1" #1: IPCOMP traffic information: in=0B out=0B
"ikev1" #1: received and ignored empty informational notification payload
"ikev1" #1: received Delete SA payload: self-deleting ISAKMP State #1
"ikev1" #1: deleting state #1 (STATE_MAIN_R3)
And why did it pick the other one again here?
We deleted (on west not on east) the ikev1 connection. And bring up
ikev1-aggr. I'm not sure if our delete on west caused east's hostpair to
be deleted or not. It probably did?
packet from 192.1.2.45:500: received and ignored empty informational notification payload
packet from 192.1.2.45:500: received Vendor ID payload [Dead Peer Detection]
packet from 192.1.2.45:500: received Vendor ID payload [RFC 3947]
packet from 192.1.2.45:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
packet from 192.1.2.45:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
packet from 192.1.2.45:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
packet from 192.1.2.45:500: received Vendor ID payload [FRAGMENTATION]
"ikev2" #3: Aggressive mode peer ID is ID_FQDN: '@west-v1'
"ikev2" #3: switched from "ikev2" to "ikev1-aggr"
"ikev1-aggr" #3: EXPECTATION FAILED at /source/programs/pluto/ikev1_aggr.c:306: c == st->st_connection
A little puzzling how it could even start with the ikev2 match first,
but it does switch to the right connection. This is where Hugh's
pexpect() hits because he didn't expect this could ever switch.
The remainder shows no more switches.....
"ikev1-aggr" #3: responding to Aggressive Mode, state #3, connection "ikev1-aggr" from 192.1.2.45
"ikev1-aggr" #3: enabling possible NAT-traversal with method RFC 3947 (NAT-Traversal)
"ikev1-aggr" #3: transition from state STATE_AGGR_R0 to state STATE_AGGR_R1
"ikev1-aggr" #3: STATE_AGGR_R1: sent AR1, expecting AI2
"ikev1-aggr" #3: NAT-Traversal: Result using RFC 3947 (NAT-Traversal) sender port 500: no NAT detected
"ikev1-aggr" #3: transition from state STATE_AGGR_R1 to state STATE_AGGR_R2
"ikev1-aggr" #3: STATE_AGGR_R2: ISAKMP SA established {auth=RSA_SIG cipher=aes_256 integ=sha group=MODP1536}
"ikev1-aggr" #3: the peer proposed: 192.0.2.0/24:0/0 -> 192.0.1.0/24:0/0
"ikev1-aggr" #4: responding to Quick Mode proposal {msgid:6eb5d4ab}
"ikev1-aggr" #4: us: 192.0.2.0/24===192.1.2.23<192.1.2.23>[@east-v1]
"ikev1-aggr" #4: them: 192.1.2.45<192.1.2.45>[@west-v1]===192.0.1.0/24
"ikev1-aggr" #4: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
"ikev1-aggr" #4: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
"ikev1-aggr" #4: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
"ikev1-aggr" #4: STATE_QUICK_R2: IPsec SA established tunnel mode {ESP=>0x7d810db7 <0x26f2f78d xfrm=AES_128-HMAC_SHA1 IPCOMP=>0x0000ccbc <0x000010e6 NATOA=none NATD=none DPD=passive}
"ikev1-aggr" #3: received Delete SA(0x7d810db7) payload: deleting IPSEC State #4
"ikev1-aggr" #3: deleting state #4 (STATE_QUICK_R2)
"ikev1-aggr" #3: ESP traffic information: in=0B out=0B
"ikev1-aggr" #3: IPCOMP traffic information: in=0B out=0B
"ikev1-aggr" #3: received and ignored empty informational notification payload
"ikev1-aggr" #3: received Delete SA payload: self-deleting ISAKMP State #3
"ikev1-aggr" #3: deleting state #3 (STATE_AGGR_R2)
packet from 192.1.2.45:500: received and ignored empty informational notification payload
"ikev2" #5: transition from state STATE_IKEv2_START to state STATE_PARENT_R1
"ikev2" #5: STATE_PARENT_R1: received v2I1, sent v2R1 {auth=IKEv2 cipher=aes_256 integ=sha1_96 prf=sha group=MODP2048}
"ikev2" #5: IKEv2 mode peer ID is ID_FQDN: '@west-v2'
"ikev2" #6: transition from state STATE_PARENT_R1 to state STATE_PARENT_R2
"ikev2" #6: negotiated tunnel [10.0.2.0,10.0.2.255:0-65535 0] -> [10.0.1.0,10.0.1.255:0-65535 0]
"ikev2" #6: STATE_PARENT_R2: received v2I2, PARENT SA established tunnel mode {ESP=>0x53fa093a <0xe242a8d2 xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=passive}
"ikev2" #5: deleting state #6 (STATE_CHILDSA_DEL)
"ikev2" #5: deleting state #5 (STATE_IKESA_DEL)
shutting down
forgetting secrets
"ikev2": deleting connection
"ikev1-aggr": deleting connection
"ikev1": deleting connection
shutting down interface lo/lo 127.0.0.1:4500
shutting down interface lo/lo 127.0.0.1:500
shutting down interface eth0/eth0 192.0.2.254:4500
shutting down interface eth0/eth0 192.0.2.254:500
shutting down interface eth1/eth1 192.1.2.23:4500
shutting down interface eth1/eth1 192.1.2.23:500
shutting down interface eth2/eth2 192.9.2.23:4500
shutting down interface eth2/eth2 192.9.2.23:500
More information about the Swan-dev
mailing list