Subject: [Mobike] issue #16

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 8 Dec 2004 11:33:07 +0100

hi all, 

i guess we can close issue # 16:  
"Can the protocol recover from situations where the only sign of problems is
lack of packets from the other end?"
http://www.vpnc.org/ietf-mobike/issue16.txt

as a conclusion of the discussions we said:

- mobike defines a mechanism to test connectivity along paths. 
- both peers might use input from other sources to detect a failure (e.g., a
local link failure)
- based on this information mobike might decide to switch to a new address
(if available). 

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 09 Dec 2004 14:54:43 -0800

Tschofenig Hannes wrote:
| hi all,
|
| i guess we can close issue # 16:
| "Can the protocol recover from situations where the only sign of
problems is
| lack of packets from the other end?"
| http://www.vpnc.org/ietf-mobike/issue16.txt

Internet paths that are silent aren't problems, IMO. They're just idle
network paths.

This sounds like a job for a link layer, and I don't think mobike needs
to be a link layer.

Joe

| as a conclusion of the discussions we said:
|
| - mobike defines a mechanism to test connectivity along paths.
| - both peers might use input from other sources to detect a failure
(e.g., a
| local link failure)
| - based on this information mobike might decide to switch to a new address
| (if available).
|
| ciao
| hannes
| _______________________________________________
| Mobike mailing list
| [email-masked]
| https://www.machshav.com/mailman/listinfo.cgi/mobike
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Tue, 14 Dec 2004 16:46:55 +0200

This issue is by the way related to #17, where we decided
that we do not assume all pairs of addresses have connectivity.
I believe the difference between #17 and #16 is that #17
talks about the connectivity upon an address change; #16
talks about whether we test/react if a currently used
path goes broken in a silent way.

I think what you say below is pretty much correct. I would
add that we really have logically two separate tests:

   (1) The one that we use when we search for a new path; I
       feel that MOBIKE needs to define this although there
       was some discussion about whether we should wait for
       some other WG to develop it for us. But this is in the
       domain of issue #17 more than for #16.

   (2) The one that we use to test that the path is still
       alive. This we already have in IKEv2, its called
       DPD. Or do you see why DPD could not be used?

And yes, we there seemed to be agreement in DC that the
path choice decisions of MOBIKE are influenced by multiple
sources, such as what DHCP/DNA/ND/L2 tell us, as well as
what DPD tells us.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 14 Dec 2004 16:50:41 +0200

> Internet paths that are silent aren't problems, IMO. They're just idle

Yes.

> This sounds like a job for a link layer, and I don't think mobike needs

The link layer certainly has its own mechanisms, as does IP on
top of it (e.g. IPv6 NUD). But these are for a link, what we are
talking about here is a path through the Internet. More specifically,
the question is what to do if IKEv2 DPD tells us that its not getting
through. Should we (a) kill the connection or (b) switch to another
address we have? I think the latter...

--Jari

---

From: Joe Touch <[email-masked]>
Date: Tue, 14 Dec 2004 11:30:57 -0800

Jari Arkko wrote:
| Joe Touch wrote:
|
|> Internet paths that are silent aren't problems, IMO. They're just idle
|> network paths.
|
| Yes.
|
|> This sounds like a job for a link layer, and I don't think mobike needs
|> to be a link layer.
|
| The link layer certainly has its own mechanisms, as does IP on
| top of it (e.g. IPv6 NUD). But these are for a link, what we are
| talking about here is a path through the Internet. More specifically,
| the question is what to do if IKEv2 DPD tells us that its not getting
| through. Should we (a) kill the connection or (b) switch to another
| address we have? I think the latter...

Links already react to things coming up and down. Routing already moves
things around links that disappear. The key question is whether IKE
should be doing something directly involving different addresses. That
starts sounding like a routing  or link management protocol, and can
(and will) interact with link or routing adjustments.

While I appreciate that IKE should retry, or allow reconecting, which
could involve different addresses (i.e., different source address used
on retry/restart), managing the addresses seems like it should be a
side-effect of the restart (leave the source address blank, let it be
filled in on exit) rather than explicitly managed. The latter is asking
for interaction with link/routing reconfiguration, in a bad way, IMO.

Joe

---

From: Jari Arkko <[email-masked]>
Date: Thu, 16 Dec 2004 16:31:00 +0200

Hi Joe,

> filled in on exit) rather than explicitly managed.

Do I interpret you correctly if I say that

(1) You are OK with explicit management of addresses
     when we have local information from the other
     parts of the stack that we need to do something,
     such as when the currently used link went down,
     ND tells us that we have moved to a new address,
     and so on.

(2) You are NOT OK with explicit management when
     DPD fails.

If this is correct, this would still leave us a
few questions, such as

o   What about other things than direct local knowledge
     that we may get from the rest of the stack. For instance,
     would explicit management be OK if you get persistent
     ICMP errors, do a DPD because of them, and then get
     a failure?

o   What does side-effect mean, exactly? Do you mean to
     say that the sender can choose any source address, as
     long as the selection is done by something lower in the
     stack than IKE? Or do you mean that source address
     selection is OK but destination address selection is not.
     Or something else?

--Jari

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Dec 2004 15:43:18 -0800

Jari Arkko wrote:
| Hi Joe,
|
|> While I appreciate that IKE should retry, or allow reconecting, which
|> could involve different addresses (i.e., different source address used
|> on retry/restart), managing the addresses seems like it should be a
|> side-effect of the restart (leave the source address blank, let it be
|> filled in on exit) rather than explicitly managed.
|
| Do I interpret you correctly if I say that
|
| (1) You are OK with explicit management of addresses
|     when we have local information from the other
|     parts of the stack that we need to do something,
|     such as when the currently used link went down,
|     ND tells us that we have moved to a new address,
|     and so on.

Not quite - I don't buy the part about the 'link going down'. All you
know is that the other end isn't reachable. Reacting to links is what
dynamic routing does; if this layer does it as well, there's liable to
be interactions (in a bad way).

| (2) You are NOT OK with explicit management when
|     DPD fails.

DPD failing means you can't talk to the other end, which means - IMO -
that the mapping you used before (name -> addr) is no longer working.
Trying a new mapping, or cycling among alternate names ought to happen
when IKE starts anyway (at the app layer).

| If this is correct, this would still leave us a
| few questions, such as
|
| o   What about other things than direct local knowledge
|     that we may get from the rest of the stack. For instance,
|     would explicit management be OK if you get persistent
|     ICMP errors, do a DPD because of them, and then get
|     a failure?

It depends on what the errors are. Some warrant a restart, some do not.
But, IMO, they warrant restart of the IKE.

| o   What does side-effect mean, exactly? Do you mean to
|     say that the sender can choose any source address, as
|     long as the selection is done by something lower in the
|     stack than IKE? Or do you mean that source address
|     selection is OK but destination address selection is not.
|     Or something else?

More that cycling among alternate addrs is something that ought to
happen on start anyway - side-effect isn't quite the right term; it's
more like 'already included explicit mechanism'.

Joe

---

From: Jari Arkko <[email-masked]>
Date: Sat, 18 Dec 2004 10:46:38 +0200

> be interactions (in a bad way).

Maybe I described it too vaguely... I did not mean just
any links -- that's in the routing domain.

If the WLAN interface of my laptop goes down there's nothing
in the routing system that reacts to this. A host is no
longer reachable at that address. End of story. But perhaps
you are thinking of links within the routing system, such
as between routers? I agree that its definately out of scope
for MOBIKE. The end hosts running IKE would not even see
this. But they would see their own interface go down, which
I think is in scope.

> when IKE starts anyway (at the app layer).
...
> But, IMO, they warrant restart of the IKE.
...
> more like 'already included explicit mechanism'.

Its unclear to me what you mean by IKE "start" or "restart". The
purpose of MOBIKE is precisely to avoid having to re-run IKE from
the beginning for a mere address change.

--Jari

---

From: Joe Touch <[email-masked]>
Date: Mon, 20 Dec 2004 09:05:14 -0800

Jari Arkko wrote:
> in the routing system that reacts to this. 

On which end? On your end, there is. On the other end, there may or may 
not be depending on the level to which dynamic routing changes are 
propagated.

> A host is no
> longer reachable at that address. End of story. 

Agnosticism is useful here; just because you can't reach the other end
does't mean you know ANYTHING for sure about why. Any link on the path
could have gone down, or any routing on the path could have failed.

> But perhaps

Seeing your own interface change and doing something seems OK - though I 
still feel it encourages YOUR IKE to interfere with YOUR dynamic routing 
(some people run that on the end host too).

> the beginning for a mere address change.

"mere" address change is the issue. It's fine to say that MOBIKE should
cycle through equivalent addresses for the same endpoint; the question
is WHEN, and how to avoid interference between dynamic routing and MOBIKE.

Joe