Subject: [Mobike] Issue 71: Failing RR (was: Do we need text about failing RR)

From: <[email-masked]>
Date: Mon, 14 Nov 2005 16:01:29 +0200

Discussing this face-to-face clarified the situation: I guess
all we need is a way for the initiator to discover the situation.

Your proposal about considering the IP address when deciding
whether to start DPD sounds like the way to go. Could you 
figure out what needs to be added and/or changed in the draft
to make this work?

Best regards,
Pasi
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 14 Nov 2005 17:25:53 +0200

> figure out what needs to be added and/or changed in the draft

Hmm...

I think we need new section probably after "Failure Recover and
Timeouts" explaining DPD behavior:

X.X Dead Peer Detection

  MOBIKE protocol uses same DPD method than normal IKEv2, but as the
  IP addresses might change in the MOBIKE also they should be taken
  account when determing whether the other peer is alive and in sync
  with address updates. This means that, if there is incoming traffic,
  but that does not use current address pair, that should not be
  considered to proof that the other end is alive. 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Nov 2005 20:49:29 +0200

>  considered to proof that the other end is alive. 
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."

--Jari

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 16 Nov 2005 13:33:44 +0200

>     with this node and or that the peer has received all address

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