Issue 36: Handling UNACCEPTABLE_PATH

Tero Kivinen (2005-07-12):
> 3.4  UNACCEPTABLE_PATH notification payload
> 
>    The responder can include this notification payload in an
>    INFORMATIONAL exchange response to indicate that the address change
>    in the corresponding request message (which contained a CHANGE_PATH
>    notification payload) was not carried out.
> 
>    The Notify Message Type for UNACCEPTABLE_PATH is TBD-BY-IANA
>    (40..8191).  The Protocol ID field is set to one (1), and SPI Size
is
>    set to zero.  There is no data associated with this Notify type.
 
There is a problem in case the UNACCEPTABLE_PATH is not for address in
the IP header but some other address pair. I mean the initiator sends
packet with IPA1, IPB1 N(CHANGE_PATH). That reaches the responder, but
he decides to send N(UNACCEPTABLE_PATH) back. The reply never reaches
the initiator because of uni-directional connection or something. The
initiator retransmits the packet with IPA2, IPB2 N(CHANGE_PATH). This
would be ok for the responder, but as he has already generated the
reply N(UNACCEPTABLE_PATH) he will retransmit that back. This will
reach the initiator and he will be receiving wrong information which
path was unacceptable.
 
**************************
I could not quite understand this.  Why would the responder send the
reply N(UNACCEPTABLE_PATH) to the request with the new address pair?  I
think the responder should check the IP address to see if this is
acceptable, and send the response according to this check.  If the new
address pair is ok, then it should snot send the N(UNACCEPTABLE_PATH).
 
One more comment on UNACCEPTABLE_PATH.
Section 2.3 says,
o  If the response contains an UNACCEPTABLE_PATH notification
      payload, the initiator MAY select another path and retry the
      exchange, keep on using the current path, or disconnect.

It is not very clear which path is meant by 'current path'.  Is current
path the old path or new path?  If it's a new path, then it would not
make sense because this path is not acceptable from the responder.   If
it's an old path, then the initiator cannot just keep on using the
current path, because its IKE SA address has already been changed.   So
in this case, the initiator should update the IKE SA to the previous
path.  Then the question is 'should the initiator perform the change
path procedure again or would it just stop after changing the IKE SA?'
It would be simpler to do the change path procedure again from MOBIKE
state machine point of view, I think.


BR,
Heeseon