Subject: [Mobike] Issue: Should MOBIKE react to problems not known locally (#NEW)

From: Jari Arkko <[email-masked]>
Date: Mon, 21 Jun 2004 18:25:48 +0300

Should MOBIKE only react to problems that are known
to the nodes locally? For instance, if an interface
in a host goes down, or it is assigned a new address,
then the node knows about this and can tell its peer.

Or should MOBIKE also deal with other problems, typically
based on the symptom of not getting packets through?
For instance, should MOBIKE attempt to do a failover
upon seeing

- DPD failure
- ICMP error
- No response to the MOBIKE protocol messages
- No incoming payload packets

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

---

From: Greg Daley <[email-masked]>
Date: Tue, 22 Jun 2004 09:59:40 +1000

Hi Jari,

> - No incoming payload packets

I think that there's obviously an issue with
using a mechanism which isn't in itself secured
to indicate changes.

This may prevent generic ICMP being used.

The incoming payload packets or MOBIKE messages
may be another matter, although it's worth
considering that an orchestrated DoS attack
against devices on the path between the two endpoints
could be used to force selection of another path
which is preferable to the attackers.

I think these are generic concerns with such backup
procedures though, not just for MOBIKE.

Greg

---

From: Satoshi Inoue <[email-masked]>
Date: Tue, 22 Jun 2004 17:10:23 +0900

On Mon, 21 Jun 2004 18:25:48 +0300

> - No incoming payload packets

failover to clear SAs? If so, then it sounds like it's out of scope
for MOBIKE.
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Tue, 22 Jun 2004 12:28:20 +0300

> failover to clear SAs? If so, then it sounds like it's out of scope

Do you mean that based on these "indirect" indications,
MOBIKE would terminate the SAs? I think this is not necessary,
normal IKEv2 mechanisms such as DPD will take care of it.

However, the question is whether a MOBIKE node should
attempt to use the peer's other address if one address
seems not to work. (This would be in addition to using
another address if the peer *told* you to use another
address.)

--Jari

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 22 Jun 2004 12:52:23 +0300

> using a mechanism which isn't in itself secured

To indicate that there might be change, and we should start checks and
perhaps a recovery. I.e. if we do not get any replies for out IKE
packets then we should try to use other address for the other end,
even when it have not send notification asking us to move to that
address. The reason that address might be broken could be some router
alogn the path which is dropping all packets. The other end cannot
know that, thus it cannot send notifications to us, asking us to move
to another address.

ICMP host unreachable, can also used to trigger a dead peer detection
check for the IKE sa, just to verify whether the IP-addresses still
work. 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Satoshi Inoue <[email-masked]>
Date: Tue, 22 Jun 2004 19:14:58 +0900

On Tue, 22 Jun 2004 12:28:20 +0300

> normal IKEv2 mechanisms such as DPD will take care of it.

Exactly.

> another address if the peer *told* you to use another

Oh, yes, I think it should.
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Thu, 24 Jun 2004 19:28:47 +0200

In your previous mail you wrote:

   
   - DPD failure
   - ICMP error

=> of course you mean "No responde to the IKE protocol messages"

=> first this is a policy issue as we don't want to define an extra
problem detection mechanism. Second IMHO this is a generic issue,
i.e., this should be handled by generic (in opposion to MOBIKE
specific) mobility or multi-homing control mechanisms. BTW we'll share
the possible security issues of these mechanisms too. And of course
MOBIKE mechanisms and policies have to follow indications from
this generic control stuff (i.e., my opinion is yes to everything).

Regards

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