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

[D. Hugh Redelmeier]

| From: Paul Wouters <paul at xelerance.com>

| 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.

Yeah.  My fault.  I implemented impair* as a tack-on.  It didn't get
documented and it piggy-backed on the debug flags.  There were four
and they did things that users probably would not want to do.

The first step to making it better is to document it.  Just explaining
it will help one decide what the right way to do it is.

BTW, looking at some code from 2003 I found what looks like a typo still in Openswan:
programs/pluto/whack.c:713:    { "debug-all]", no_argument, NULL, DBGOPT_ALL + OO },
Surely that closing square bracket does not belong.  Why has it not caused problems?

| 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?

The impair options are supposed to break bits of Pluto in ways thought
useful for testing.  The impair-bust-mi2/impair-bust-mr2 do what they
were always meant to do: generate large VID payload to push the UDP
packet over 1500 bytes (the presumed MTU).

The results of this are another matter.  You might wish to adjust if
your MTU is larger than 1500, for example.

Summary: the impair-bust-m[ir]2 code looks OK but it may no longer
have the effect you want.