[Swan-dev] FYI, IKEv2's next payload dance no longer needed;

Andrew Cagney andrew.cagney at gmail.com
Wed Apr 18 01:07:02 UTC 2018

For instance, code like this:

                .np = IMPAIR(ADD_BOGUS_PAYLOAD_TO_SA_INIT) ?
                        (vids != 0) ? ISAKMP_NEXT_v2V : ISAKMP_NEXT_v2NONE,

should no longer be needed.  Instead, when adding a new payload to a
message, just leave the new payload and the preceding payload
next-payload fields blank (aka 0), packet.c will fill the blanks.

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)
- fill in the missing values


---------- Forwarded message ----------
From: Andrew Cagney <cagney at vault.libreswan.fi>
Date: 17 April 2018 at 19:09
Subject: [Swan-commit] Changes to ref refs/heads/master
To: swan-commit at lists.libreswan.org

New commits:
commit 4447950353bc4f97c717eeae58f67ede7fa4c15c
Author: Andrew Cagney <cagney at gnu.org>
Date:   Sun Apr 15 00:20:25 2018 -0400

    packets: always update (prefered) or cross-check (legacy) IKEv2's
next-payload-type field with the actual payload's type

    Treat anything else as an error.

    The next-payload-type (.np) field of outgoing IKEv2 payloads no
    longer needs to be set as packet.c will set it autmatically.
    (In fact, when trying to add a payload to old code all the NP
    guff should be stripped out).

Swan-commit mailing list
Swan-commit at lists.libreswan.org

More information about the Swan-dev mailing list