[Openswan Users] Bad Transform in ISAKMP message

[Shaheen Ali]

Hello everyone,

I have been using openswan for about 6 months now very successfully.  From
the beginning we have focused on interop testing and making sure that
everything worked in well behaved environments.

But...

I started doing some negative testing against openswan and discovered
something that does not square with RFC2408.

According to the RFC, if there are multiple transforms and one of the
transforms is bad, that transform should be skipped and processing should
move onto the next one.

So I created a phase 1 identity protection message.  The msg contained one
SA with one proposal.  The proposal held two transforms.  The second
transfom was good specifying transform 3des-sha1 with PSK.  The first
transform was bad.  The first transform specified nonsense attributes. 
The first transform also set the Transform ID field to 0 rather than the
required value of one.

Pluto complained about the bad transform ID when calling
in_struct(...&isakmp_isakmp_transform_desc...) on that transform.  It
complained that the transform ID was an unknown value (0).

Now, it is OK to complain.  But pluto failed to process the correctly good
transform and dropped the message entirely.

This doesn't seem right since RFC2408 Section 5.6, page 65 states that a
BAD PROPOSAL SYNTAX message may be returned but that the rest of the
transforms must be processed.

I am running 1.0.9, but it seems this bug is also in 2.3.0 and maybe even
later.  Am I missing something?  It seems that openswan has a conformance
problem.

Shaheen