[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