[Note I'm not on the ethereal-dev list so make sure to CC me in any replies]
On Mon, Nov 29, 1999 at 06:44:04PM -0800, Guy Harris wrote:
> > -static void dissect_transform(const u_char *, int, frame_data *, proto_tree *);
> > +static void dissect_transform(const u_char *, int, frame_data *, proto_tree *,
> > + guint8);
Yeah, I should have mentioned that it was a hack, it works but is ugly.
The problem is that the attributes in a transform payload have different
meanings depending on the protocol in the proposal header. During
phase-1 when negotiating an ISAKMP transform they have completely
different meanings then during phase-2 when negotiating an AH or ESP
transform.
I didn't see a way, with the arguments given, to determine what protocol
proposal this transform payload belongs to so I added an extra
argument as a quick hack.
> "dissect_transform()" is also called from "dissect_isakmp()", through a
> pointer in the "strfuncs[]" array:
>
> if (hdr->next_payload < NUM_LOAD_TYPES)
> (*strfuncs[hdr->next_payload].func)(pd, offset, fd, isakmp_tree);
> else
> dissect_data(pd, offset, fd, isakmp_tree);
It turns out that dissect_transform() will never be called from here.
The main chain of "next_payload"s should NEVER include proposal or
transform payloads. An SA (security association) payload will be in the
main chain and it will have next_payload and length fields pointing past
the proposals it contains. Similarly the contained proposals will have
next_payload values of only 0 (none) or 2 (proposal) and won't mention
the contained transform payloads (which can only have next_payload
values of 0 or 3).
For example, the first packet of an aggressive mode phase-1 exchange
might have the following structure:
initiator cookie
responder cookie 0
next payload 1 (Security Association)
version 0x10 (1.0)
exchange type 4 (Aggressive)
flags 0
message id 0
length 374
Security Association Payload:
next payload 4 (Key exchange)
length 100 (includes embedded proposal payloads)
...
Proposal Payload:
next payload 0 (none)
length 88 (includes embedded transform payloads)
proposal number 0
protocol id 1 (ISAKMP)
...
Transform Payload:
next payload 3 (transform)
length 36
transform # 0
...
Transform Payload:
next payload 0 (none)
length 36
transform # 1
...
Key Exchange Payload:
next payload 10 (nonce)
length 132
...
Nonce Payload:
next payload 5 (identification)
length 20
...
Identification Payload:
next payload 13 (vendor id)
length 34
...
Vendor ID Payload:
next payload 0 (none)
length 20
...
So the real problem involves fixing dissect_proposal() and the way the
dissect function calls are chained together. This was beyond the scope
of the patch I provided.
--
Dave Chapeskie <dchapes@xxxxxxxxx>
