[Openswan dev] --impair-* and plutodebug interaction

[Paul Wouters]

On Wed, 22 Dec 2010, Paul Wouters wrote:

> I noticed that when trying to use the --impair-* functions for testing,
> that these did not seem to work. Adding some debugging, I found something
> curious.
>
> If you set plutodebug=all, then it seems the IMPAIR* settings are lost.
>
> This also means that when you want to test something, for instance by adding
>
> 	plutoopts="--impair-bust-mi2 --impair-bust-mr2"
>
> You may not set plutodebug=all which is bad because this is used specifically for
> testing and debugging when you want all the logs.
>
> Is this a bug, or was this done by design?

I confirmed this was already the case in openswan 2.4.x

> Though I also noticed that not setting plutodebug= did not trigger the above two
> impair functions to work.

Actually it is slightly more subtle. When using the --impair-bust-mi2/--impair-bust-mr2
functions, a vendorid of all zeroes is send/received. We log this and continue:

104 "icmp" #1: STATE_MAIN_I1: initiate
003 "icmp" #1: received Vendor ID payload [Openswan (this version) 2.6.32rc10 ]
003 "icmp" #1: received Vendor ID payload [Dead Peer Detection]
106 "icmp" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "icmp" #1: ignoring unknown Vendor ID payload [0000000000000000000000000000000000000000000000000000000000000000...]
108 "icmp" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "icmp" #1: received Vendor ID payload [CAN-IKEv2]
004 "icmp" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_sha group=modp2048}
117 "icmp" #2: STATE_QUICK_I1: initiate
004 "icmp" #2: STATE_QUICK_I2: sent QI2, IPsec SA established transport mode {ESP=>0x8ccfe1ef <0x609f87b1 xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=none}

I think this code assumed that openswan/freeswan would abort negotiation on receiving an
unknown vendorid, but that this behaviour has changed, breaking these debugging functions.

I think an explicit return STF_IGNORE should now happen instead when we receive the "null vendor id".

dhr: can you confirm any of my reasoning?

Paul