[Swan-dev] why, in ah-pluto-01, does libreswan emit an ESP proposal

Andrew Cagney andrew.cagney at gmail.com
Thu Oct 4 14:33:17 UTC 2018


For instance, http://testing.libreswan.org/results/testing/v3.22-1007-g86105a8-master/ah-pluto-01/
(its seemingly being doing it for a while):

west.conf has:

conn westnet-eastnet-ah
    also=west-east-base
    also=westnet
    also=eastnet
    phase2=ah

but in west's logs I see:

| ikev1_out_sa pcn: 0 has 1 valid proposals
| ikev1_out_sa pcn: 0 pn: 0<1 valid_count: 1 trans_cnt: 1
| ****emit ISAKMP Proposal Payload:
|    next payload type: ISAKMP_NEXT_NONE (0x0)
|    proposal number: 0 (0x0)
|    protocol ID: PROTO_IPSEC_AH (0x2)
|    SPI size: 4 (0x4)
|    number of transforms: 1 (0x1)
...
| emitting length of ISAKMP Transform Payload (AH): 28
| emitting length of ISAKMP Proposal Payload: 40
| ikev1_out_sa pcn: 1 has 1 valid proposals
| ikev1_out_sa pcn: 1 pn: 0<1 valid_count: 1 trans_cnt: 1
| ****emit ISAKMP Proposal Payload:
|    next payload type: ISAKMP_NEXT_NONE (0x0)
|    proposal number: 1 (0x1)
|    protocol ID: PROTO_IPSEC_ESP (0x3)
|    SPI size: 4 (0x4)
|    number of transforms: 1 (0x1)
...

on east, it grabs the first proposal:

| ****parse ISAKMP Proposal Payload:
|    next payload type: ISAKMP_NEXT_NONE (0x0)
|    length: 40 (0x28)
|    proposal number: 0 (0x0)
|    protocol ID: PROTO_IPSEC_AH (0x2)
|    SPI size: 4 (0x4)
|    number of transforms: 1 (0x1)
...
| AH IPsec Transform verified unconditionally; no alg_info to check against

(it shouldn't see the second proposal because NEXT==0 in the first proposal)

In the current code NEXT in the first payload is patched up so the
second proposal is be visible.  Am trying east:phase2=esp
(Found this while testing a local patch that only verifies the (IKEv2
term) Last Substructure field - after all both IKEv1 and IKEv2 have
had this working since forever and, unlike the Next Payload chain,
computing this ahead of time is "easy")


More information about the Swan-dev mailing list