Designing RR for IKEv2 based mobility

Hi,

I changed the name to keep this discussion separate from the one on 
whether RR should be optional.

Please see inline:

[email protected] wrote:

>Dondeti, Lakshminath wrote:
>  
>
>>I did not think of the 'sending of protected TCP ACKs to fake
>>liveness' :-), but that prompts me to say that RR should
>>require the client to decrypt the RR request message, and send
>>a reply with information from within the request message.  If
>>the protocol were to send an empty informational message,
>>wouldn't the client be able to "expect the time of the
>>request" and send a valid "response?"
>>    
>>
>
>This is actually a very good point! It seems that in IKEv2
>an empty informational exchange does not guarantee RR,
>since the client could generate the response without 
>actually seeing the request...
>
>  
>
Thanks.

>Perhaps we could re-use the COOKIE Notify payload for this?
>That is, when the gateway receives a request to update the SAs,
>it could reply with a COOKIE payload and the client would
>re-send the request with the cookie? This way, RR could be also
>skipped if necessary (for instance when switching back to an
>address that was already tested recently).
>  
>
>This, of course, means that the address update request has 
>to be sent from the new address (since the reply containing the 
>cookie goes to the source address of the IKEv2 packet). This 
>may also complicate "path failover" since it may be possible 
>that a packet containing an address update request would be 
>used for path testing... 
>
>Personally I think it would be also acceptable to do the RR 
>check after changing the address. That is, the gateway updates 
>the SAs immediately, but then sends a separate informational 
>exchange containing some kind of cookie. What do others think
>about this?
>
>  
>

I prefer that the address update exchange be independent of the RR 
exchange.  The mobile host then would still be free to send the address 
update before or after the move.  The IPsec GW may send a RR request (to 
the new address, of course) containing, as you note, a fresh (warm? :-) 
) COOKIE (does not need to be huge as the host gets only one attempt, if 
it chooses to guess; in fact, if the "guess" is incorrect, the GW MUST 
delete the host's credentials) expecting the host to reply with the same 
COOKIE in the Notify payload.

regards,
Lakshminath

>Best regards,
>Pasi
>
>  
>