Subject: [MOBIKE] Issue 36: Handling UNACCEPTABLE_PATH

From: "Heeseon Lim" <[email-masked]>
Date: Wed, 13 Jul 2005 18:19:00 -0700

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
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 14 Jul 2005 12:13:02 +0300

> reach the initiator and he will be receiving wrong information which

Because the message ID is same and once a request or reply for that
message id is generated it must be retransmitted without any
modifications. 

> 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).

That would be ok, if this would be the different message, but as it
could be retransmission of the same message it must be sent back
simlarly than before.

Lets take example. We have ip-addresses of A1, A2, B1, and B2, and the
responder feels that A1 is not allowed because of the policy.

Now A sends update.

Initiator				Responder
=========				=========
(A1, B1) N(CHANGE_PATH), N(COOKIE2) ->

					Responder notices that the
					header has A1, so he decides
					to send N(UNACCEPTABLE_PATH)
					back.
			lost	<- (B1, A1) N(UNACCEPTABLE_PATH)

The N(UNACCEPTABLE_PATH) from
responder was lost because of
unidirectional link.

A retransmits the packet:

(A1, B1) N(CHANGE_PATH), N(COOKIE2) ->

					B sees retranmissions, and
					replies with the
					retransmission packet.

			lost	<- (B1, A1) N(UNACCEPTABLE_PATH)

The N(UNACCEPTABLE_PATH) is still
lost.

A notices he is not getting packets
back, so he decides to try to use some
other IP-address:

(A1, B2) N(CHANGE_PATH), N(COOKIE2) ->

					B retransmits its previous
					packet.

			lost	<- (B2, A1) N(UNACCEPTABLE_PATH)

A tries again:

(A2, B2) N(CHANGE_PATH), N(COOKIE2) ->

					B retransmits its previous
					packet.

				<- (B2, A2) N(UNACCEPTABLE_PATH)

Now the A do receive the packet
and notices that the path was
unacceptable, but he does
not know which path was
unacceptable: (A1, B1), (A1, B2) or
(A2, B2).

It could have been so that the (A1, *)
packets never reached the responder,
and only thie (A2, B2) packet reached
the responder, and that path was
unacceptable, or it could be like now
that the (A1, B1) path was unacceptable.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Sat, 30 Jul 2005 18:20:35 +0300

>reach the initiator and he will be receiving wrong information which
Agreed.

>Fixing this is quite simply, we add the address pair that was
>unacceptable to the notify data. In case there is NAT in the path the
>responder might not recognize all the addresses, but in case of no
>NATs it immediately knows which address pair wasn't acceptable. 
>  
>
Hmm. Maybe it would then be better to introduce a counter
or message id to N(CHANGE_PATH) and N(UNACCEPTABLE_PATH)
rather than the addresses, which can change en-route?

--Jari