On 19 April 2018 at 09:16, Paul Wouters <[email protected]> wrote: > On Tue, 17 Apr 2018, Andrew Cagney wrote: > >> This, of course, isn't true of IKEv1, if anyone is so motivated the >> process is straight forward: >> - tweak below so it just logs (and doesn't return an error) >> - change next-payload-type fields to either ft_mnp (message) or ft_pnp >> (payload)
(there's an extra step, see below) #include rant about how the next payload field in the RFC was such a bad idea > What is the difference between ft_mnp and ft_pnp? > > I don't understand the meaning of "message" vs "payload" ? In IKEv2, both the message header (oops, I should be calling it the IKE header) https://tools.ietf.org/html/rfc7296#section-3.1 and the payload header https://tools.ietf.org/html/rfc7296#section-3.2 have a next payload field. I suspect IKEv1 is the same. The code (which implements DHR's idea) needed to handle the two headers differently so I gave them different types: ft_mnp: save the message header's next payload field location in the message digest, ready for ... ft_pnp: find the message digest (it contains the last next payload location) if needed, set the saved (now previous) next payload field to this payload's type else check things are somewhat sane save this payload's next payload field location in the message's digest, mix, repeat looking at packet.c, the shared isakmp_hdr_desc has already been updated to ft_mnp. This leaves: #1 changing the type of the next payload field in the individual IKEv1 payload descriptors from: { ft_enum, 8 / BITS_PER_BYTE, "next payload type", &payload_names_ikev1 }, to: { ft_pnp, 8 / BITS_PER_BYTE, "next payload type", &payload_names_ikev1 }, #2 and set the .np field in descriptors like: struct_desc isakmp_sa_desc = { "ISAKMP Security Association Payload", isasa_fields, sizeof(struct isakmp_sa), 0, }; to (I'm guessing): struct_desc isakmp_sa_desc = { .name = "ISAKMP Security Association Payload", .fields = isasa_fields, .size = sizeof(struct isakmp_sa), .np = ISAKMP_NEXT_SA???, }; While the actual changes look trivial, quirks like b2bd0f1b080d6cf5272b1f746bd3d3d0642cd60b, meant it was safer to perform the second step incrementally: run the testsuite, grep for the relevant debug log lines, and then fix one case; repeat. I need a faster machine :-) Andrew _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
