[strongSwan-dev] Removing peer client in pluo quick_inI1_outR1_tail()

[Steve William]

Hello all,

I have seen from http://wiki.strongswan.org/projects/strongswan/repository/revisions/master/changes/src/pluto/ipsec_doi.c
that the sequence of code below is present in strongswan project code since the file was under version control.


static stf_status quick_inI1_outR1_tail(struct verify_oppo_bundle *b,
                                        struct adns_continuation *ac)
{
.........................
        if ((st->nat_traversal & NAT_T_DETECTED)
        &&
 (st->st_esp.attrs.encapsulation == ENCAPSULATION_MODE_TRANSPORT)
        && (c->spd.that.has_client))
        {
            /** Remove client **/
            addrtosubnet(&c->spd.that.host_addr, &c->spd.that.client);
            c->spd.that.has_client = FALSE;
        }
.........................
}

I
 wanted to ask you if you know the reason behind this change, becouse I 
get some problems at rekey time, in the case when the initial IPSec 
responder, initiates the Quick Mode to re-establish the Phase 2 SA, as a
 result of Phase 2 SA lifetime expiration. The problem is that the 
client address of the peer gets changed for the
 connection, and when the connection initiator receives the first Quick 
Mode message from the responder (that is now the initiator) the 
following situation arise:


// This is on the initial initiator, now the responder of the first Quick Mode message from initial responder.


.................................

| ***parse ISAKMP NAT-OA Payload:                           
|    next payload type: ISAKMP_NEXT_NONE                    
|    length:
 12                                                            
|    ID type: ID_IPV4_ADDR                                   
| removing 4 bytes of padding                                
| HASH(1)
 computed:                             
|   c9 03 43 ba  50 ce 55 c7  8d fa 55 58  aa ed ad 66
|                                                               
######  CUSTOM_DEBUG: quick_inI1_outR1 conn:ixtun00168 this.client.addr:13.1.0.174
 that.client.addr:14.1.0.174
                                                                                                                     
| peer client is subnet
 14.1.0.174/32                                                                                
| peer client protocol/port is 0/0                   
| our client is subnet 14.1.0.1/32                              
| our client protocol/port is
 0/0                                                                     
| find_client_connection starting with ixtun00168                                          
|   looking for 14.1.0.1/32:0/0 -> 14.1.0.174/32:0/0 
|   concrete checking against sr#0 13.1.0.174/32 -> 14.1.0.174/32
|    match_id
 a=14.1.0.174                              
|             b=14.1.0.174                                      
|   results  matched                                   
|   trusted_ca called with a=(empty) b=(empty)       
|   fc_try trying ixtun00168:14.1.0.1/32:0/0 -> 14.1.0.174/32:0/0 vs ixtun00168:13.1.0.174/32:0/0 ->
 14.1.0.174/32:0/0
|   fc_try concluding with none [0]                                                
|   fc_try ixtun00168 gives none                                                                                     
|   checking hostpair 13.1.0.174/32 ->
 14.1.0.174/32 is not found                                     
|   concluding with d = none                                                                          
|                                                                                                                    
######  CUSTOM_DEBUG: quick_inI1_outR1_authtail set me.client.addr:14.1.0.1                         
######  CUSTOM_DEBUG:
 quick_inI1_outR1_authtail set he.client.addr:14.1.0.174
                                                              
"ixtun00168"
 #1339: cannot respond to IPsec SA request because no connection is 
known for 14.1.0.1/32===13.1.0.174:4500[S?C]...14.1.0.174:4500[S?C]
| =>complete_state_transition                              
.............................

The check: fc_try trying ixtun00168:14.1.0.1/32:0/0 -> 14.1.0.174/32:0/0 vs ixtun00168:13.1.0.174/32:0/0 -> 14.1.0.174/32:0/0
should be
                 fc_try trying 
ixtun00168:14.1.0.1/32:0/0 -> 14.1.0.174/32:0/0 vs 
ixtun00168:13.1.0.174/32:0/0 -> 13.1.0.174/32:0/0.


If the responder would have not removed the client in the code snapshot above, then the problem would not arise.

That's
 why I wanted to ask you if you know the real reason behind that code. 
If not completely remove, maybe we may add a new check for 
NAT_TRAVERSAL_NAT_BHND_ME, or we may skip removing the client in the 
test.

Waiting for your reply.

Thank you,
Daniel.