RE: issue #16

hi all, 

maybe we get a little bit lost on this particular issue. what are we
discussing here? here is my short summary: 

a) mobike might get information from other protocols. this might indicate
that there is something wrong with the currently selected preferred address.
mobike does not specify with which protocols it needs to interact and it
does not specify the policy for changing the preferred address. this is
implementation dependent. 

b) there is also a mechanism to detect that something happened along the
path between the ikev2 initiator and the ikev2 responder using some sort of
message exchange (we called it dead-peer detection - which is not the best
name for it; sctp folks called it heartbeat).
this message exchange might reveal that something is wrong along the path
between from a given source address towards a destination address. this
might require a new preferred address to be selected. this new preferred
address needs to be communicated to the other ikev2 peer. 
the format of these messages will be found in a mobike specification. 

btw, we are not the first discussing this area. there has been a lot of work
in the context of sctp on this issue. i have the impression that they have
the same view on it.

hence, i think that there are not particular problems here (except that we
are a little bit struggling with terminology issues). 

ciao
hannes


Jari Arkko wrote:
> Joe Touch wrote:
> 
>> | (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).
> 
> 
> 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. 

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
> 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.

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).

>> Trying a new mapping, or cycling among alternate names ought to happen
>> when IKE starts anyway (at the app layer).
> 
> ...
> 
>> It depends on what the errors are. Some warrant a restart, some do not.
>> But, IMO, they warrant restart of the IKE.
> 
> ...
> 
>> 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'.
> 
> 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.

"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