[Openswan dev] Design question: ikev2 state change signifying partial success?
D. Hugh Redelmeier
hugh at mimosa.com
Tue Feb 21 12:56:17 EST 2012
| From: Paul Wouters <pwouters at redhat.com>
I've not yet taken the time to read and understand your whole message.
So the rest of this might be way off base.
[going very abstract]
First, what are states (enum state_kind values) in Pluto? They
reflect where we are in a negotiation, between events. During the
processing of events, many things are up in the air and the state will
be in transition. During processing, the fine details of where we are
in negotiation is reflected in where we are in the code.
Conceptually it sounds as if your problem is that one of the messages
has been partially successful and you have no way of signifying it in
with enum state_kind. I think that that indicates the current
enum state_kind is wrong for V2 (not expressive enough).
In IKE V1, it was pretty easy to treat the place in the sequence of
messges of a negotiation as the state of negotiation: a message was
either accepted or rejected. Furthermore, in a particular kind of
exchange, each payload came in a standard-specified message.
If I recall, V2 lets payloads be in any of several messages and you
can drag out or compress the exchange as much as you want.
This means that the state of negotiation may not be the same as the
place in the sequence of messages of an exchange.
If the payloads were in a fixed order, even if not in a fixed message,
you could think of the state as being the position in the sequence of
payloads. On the downside, this multiplies the number of states.
If the payloads are not in a fixed order, then states could be
identified with the set of transmitted payloads and received payloads.
(I think some orders are forbidden: certain payloads are needed to
create the IKE SA and must be before that happens and certain payloads
must be protected and thus be after.)
Anyway: you get the idea. The state needs to reflect what has been
done and (perhaps implicitly) what still needs to be done. At least
for all points between events.
More information about the Dev
mailing list