-------------------- 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. 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. -------------------- Heeseon Lim (2005-07-14): 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. -------------------- Tero Kivinen (2005-07-14): > 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 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. > 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). 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. -------------------- Jari Arkko (2005-07-30): >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. > > 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? -------------------- Pasi Eronen (IETF63 presentation): Issue 36: Unacceptable_Addresses Unacceptable_Addresses - If Update_SA_Addresses message was retransmitted with different src/dst IP, we don't know which path was unacceptable - Because can't add/change anything to the messages after they have been sent once - My proposal: - The initiator knows if it has retransmitted the message with several addresses - If it has, just try again (send a new Informational request with Update_SA_Addresses) -------------------- IETF63 MOBIKE WG minutes: 36: Unacceptable addresses. Receiver might not know which address set was acceptable Jari A: I had different thoughts on the list, but it is clarified now and I am ok with this. Pasi: This is a corner case anyway -------------------- Jari Arkko (2005-08-15): Issue 36: Unacceptable addresses. There are cases where the initiator does not know which one of the retransmitted requests was really the one seen by the responder and resulted in the unacceptable address error. Pasi's solution for this is to send a new request in this (corner) case. -------------------- Tero Kivinen (2005-08-23): Now when I have had some more time to think about this, I think Pasi's solution is the best. My original proposal (include the addresses in the notify) might have some issues with NATs, so I think the Pasi's solution is better. -------------------- Pasi Eronen (2005-08-30): I started editing the draft to make this change, but then noticed the functionality is actually already there. Version -01 says o If a new address change occurs while waiting for the response, starts again from the first step (and ignores responses to this UPDATE_SA_ADDRESSES request). So in the ambiguous situation (UPDATE_SA_ADDRESSES request has been sent using several different src/dst addresses, and we don't know which of them was unacceptable), it already says we ignore the response and a new request is sent. (But I'll clarify this in -02; also the response is not really totally ignored, just not processed by MOBIKE.) --------------------