The history of the internet is littered with such problems (Secure HTTP is the wrong way around for instance) based on the assumptions of the time.

If you realy wanted to reduce DoS you need to minimise the load on the Responder as much as possible. To do this you will need to split the communication up into seperate stages “Open connection”, “data transfer”, “Close connection” etc. So for opening a connection you would make,

1, All Responder State precomputable.
2, All messages conectionless.
3, The Initiator path more expensive than for the Responder.
4, All “expensive” state storage by the Initiator.
5, All non data Responder acks/replies limited in cost both in packet size and computational load.

Oh and secure would be nice providing it does not conflict with the above requirments

Having made the “Open Connection” expensive for the Initiator, and having (probably) forced them into giving you a valid IP address you would move onto the next stage. This is a different problem which can be addressed in another way but similar in principle. When you get to the “Data Transfer” stage you obviously want this to be secure and balanced to reduce network overhead

From what you have shown above JFKr does not meet all of the above requirments in the setup as message 2 (from the Responder) shows. It is neither computationaly cheep or pre-computable and happens at a time when you have not achived a level of confidence about the Initiator.