issue 31 -- responder address changes

Tero wrote:

>> 2.4  Updating additional addresses
>...
>>    There is one additional complication: when the responder wants to
>>    send a new additional address list, the currently used path may no
>>    longer work.  In this case, the responder uses the additional address
>>    list received from the initiator, the list of its own addresses, and,
>>    if necessary, the path testing feature (see Section 2.5) to determine
>>    a path that works, updates the addresses in the IKE_SA (but not IPsec
>>    SAs), and then sends the INFORMATIONAL request.  This is the only
>>    time the responder uses the additional address list received from the
>>    initiator.
>
>This is no way only related to the updating addresses, it might be
>also break down during any other exchange, and if the responder does
>not do try all address pairs when sending IKE packets, it will cause
>IKE SA to deleted because of timed out exchange unless the initiators
>DPD timers are much shorter than responders negotiation timeout
>timers.
>
>I mean if initiator does DPD, and notices that everything is fine,
>then address pair breaks down, and then responder starts sending some
>IKE packet. If this IKE packet manages to time out before the next DPD
>has started, and detected the problem, and found the new working
>address pair, and sent an address update by N(CHANGE_PATH) then the
>responder will delete the IKE SA
>  
>
Right.

>There are cases where the responder cannot do anything, because of the
>NATs, so in those cases this will happen anyways, but if there is no
>NATs preventing original responder for sending packets to original
>initiator then the original responder can simply try other address
>pairs, to see if them work. If not, then delete the IKE SA, if one of
>them work, fine, he did get his operation done, and original initiator
>probably got some hint about something being wrong...
>
>If we decide that we do not need this feature, then we can simply
>leave out the address lists in the responder side completely, and say
>that responder will not try to fix any situations, and it will not
>support break-before-make style movement to new addresses unknown by
>the initiator. 
>  
>
Right. But I think we want this feature.

--Jari