[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