Re: Issue 71: Failing RR (was: Do we need text about failing RR)

Jari Arkko writes:
> OK. Somewhat edited version below:
> 
>    "MOBIKE uses the same Dead Peer Detection
>     method as normal IKEv2, but as addresses may change, it is
>     not sufficient to just verify that the peer is alive, but also that
>     it is synchronized with the address updates and has not, for
>     instance, ignored an address update due to failure to complete
>     return routability test. This means that when there are incoming
>     IPsec packets, MOBIKE nodes SHOULD inspect the addresses used
>     in those packets and determine that they correspond to those
>     that should be employed. If they do not, such packets SHOULD
>     NOT be used as evidence that the peer is able to communicate
>     with this node and or that the peer has received all address
>     updates."

Looks good.

I was planning to add something like this to the design document (new
section 5.5.2 between current 5.5.1 and 5.5.2):
----------------------------------------------------------------------
5.5.2.  Return Routability Failures

   If the return routability fails, we need to tear down IKE SA if we
   are using IKEv2 INFORMATIONAL exchanges as a return routability
   checks.  On the other hand return routability can only fail
   permanently if there was an attack by the other end, thus tearing
   down IKE SA is suitable action in that case.

   There is few other cases that needs to be considered here.  In the
   first case there is no attacker, but the selected address pair stops
   working immediately after the address update, before the return
   routability check.

   What happens there is that initiator does the normal address update,
   and that succeeds, and then responder starts return routability
   check.  If the address pair has broken down before that the responder
   will never get reply back to the return routability check.  The
   responder might still be using the old IP address pair, which could
   still work.

   The initiator might be still seeing traffic from the responder, but
   using the old address pair.  The initiator should detect that this
   traffic is not using the latest address pair, and after a while it
   should start dead peer detection on the current address pair.  If
   that fails, then it should find new working address pair, and update
   addresses to that.  The responder should notice that the address pair
   was updated after the return routability check was started, and
   change the ongoing return routability check to use the new address
   pair.  The result of that return routability check needs to be
   discarded as it cannot be trusted as the packets were retransmitted
   to different IP address.  So normally responder starts new return
   routability check after that with the new address pair.

   The second case is where there is attacker along the path modifying
   the IP addresses.  The peers will detect this as NAT and will enable
   NAT-T recovery of changes in the NAT mappings.  If the attacker is
   along the path long enough to the return routability check to succeed
   then the normal recovery of changes in the NAT mappings will take
   care of the problem.  If the attacker disappears before return
   routability is finished, but after the update we have almost similar
   case than last time.  The only difference is now that the dead peer
   detection started by the initiator will succeed, as responder will
   reply to the addresses in the headers, not the current address pair.
   The initiator will then detect that the NAT mappings are changed, and
   it will fix the situation by doing address update.

   Important thing for both of these cases is that initiator needs to
   see that responder is both alive and synchronized with initiator
   address pair updates.  I.e. it is not enough that other end is
   sending traffic to initiator, it must be also using the correct IP
   addresses before initiator can belive it is alive and synchronized.
   From the implementation point of view this means that the initiator
   must not consider packets having wrong IP addresses as a packets that
   proof the other end being alive, i.e. they do not reset the dead peer
   detection timers.
-- 
[email protected]