[Swan-dev] encrypted informational message when in state R1?

Antony Antony antony at phenome.org
Wed Feb 18 23:18:21 EET 2015


Hugh,

I wonder if you noticed , all lievenss and delete messages arrive when the state is in R2. 

.story      = "R2: process INFORMATIONAL",
.state      = STATE_PARENT_R2,
.next_state = STATE_PARENT_R2,

I think we need one for this. However, in current implemention the message is droped by ikev2_decrypt_msg

we could have different procssing function for the R1 -> R1 

.story      = "R1: process INFORMATIONAL",
.state      = STATE_PARENT_R1,
.next_state = STATE_PARENT_R1,
.processor  = drop_encrypted_informational_ikev2 


On Wed, Feb 18, 2015 at 03:57:31PM -0500, D. Hugh Redelmeier 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?
> 
> 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.
> 
> 
> I continue to think that these are terrible state names.
> 
> STATE_PARENT_R1 => STATE_INIT_R
> STATE_PARENT_R2 => STATE_AUTH_R
> _______________________________________________
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev
> 


More information about the Swan-dev mailing list