[Swan-dev] encrypted informational message when in state R1?
Andrew Cagney
andrew.cagney at gmail.com
Thu Feb 19 02:34:30 EET 2015
On 18 February 2015 at 15:57, D. Hugh Redelmeier <hugh at mimosa.com> wrote:
> | From: Andrew Cagney <andrew.cagney at gmail.com>
>
> | I'm trying to understand this:
> |
> | /* Informational Exchange */
> | { .story = "R1: process INFORMATIONAL",
> | .state = STATE_PARENT_R1,
> | .next_state = STATE_PARENT_R1,
>
> I don't understand this. Maybe I will later.
>
> Why would there be support for an informational when in
> STATE_PARENT_R1 and not when in STATE_PARENT_R2?
>
> Is this a typo?
Apparently not.
> The only states that support ISAKMP_v2_INFORMATIONAL in the current
> code are STATE_PARENT_I2, STATE_PARENT_R1, and STATE_PARENT_I3, in
> that order. Sure feels like a typo.
Except INFORMATIONAL messages are not supported/allowed in STATE_PARENT_R1
The above just makes one think they are. Code, further in, then drops them.
Anthony's suggesting changing the above to:
.story = "R1: process INFORMATIONAL",
.state = STATE_PARENT_R1,
.next_state = STATE_PARENT_R1,
.processor = drop_encrypted_informational_ikev2
where my preference is to replace it with the comment:
/* STATE_PARENT_R1 does not allow INFORMATIONAL messages */
> I continue to think that these are terrible state names.
>
> STATE_PARENT_R1 => STATE_INIT_R
STATE_INIT_REPLIED?
> STATE_PARENT_R2 => STATE_AUTH_R
I've not come up with better.
Andrew
More information about the Swan-dev
mailing list