Re: issue 11 -- window size

 > > 1) Define a separate window for PATH_TEST messages
> 
> Hmm... I am not sure what you mean by that. Can you exlain it more.
> 
This is one way to do it, but not the only way to do it. Define a new flag
value indicating "Mobility messages". The message-id carried in the
IKE header has its own window space. Thus not constrained by
the current window used by "normal IKEv2 messages". This can
be used by PATH_TEST in the same way as you described. 
Message-ids can be used to match request to response and hence
you know which path works. Would that work ? 

> > 2) Do the PATH_TEST message outside the protection IKE SA [MOPO
> >    protocol] 
> 
> Yes, that is another option. I just send my proposal to offer another
> option for that proposal :-)
> 
I am not sure i understood this. Are you saying that your PATH_TEST option
could be used by MOPO or something else ?

> > Another advantage of keeping PATH_TEST message separate (like in (1)
> > and (2) above), is that we can look for a new PATH even when there
> > is no failure. This might be a useful feature. I don't know whether
> > it is possible with Tero's proposal.
> 
> My proposal didn't give out any exact details of the path test
> process, but as it will be done for all packets, you can use DPD
> packets to do it, for example you could make the DPD path test checks
> so that they will always start the different address pair, so that
> finding of list of working address pairs happens on the background
> during the DPD tests. When the actual failure happens the path test
> process could use that information too.
> 
Ok, the other end knows that it is "DPD path" test, so just reply and don't affect
the SAs. 

> On the other hand, I do not think there is that much value for the old
> information, as clearly something has changed in the paths as the
> current (previously working address pair) has stopped working, thus
> all the old information we have might be obsolete now anyways.
> 
Agreed that it is a potential problem. But perhaps it can be used 
as a hint to start trying from the address pair that was known to
work sometime back. Implementations can be smart enough to age the information
and periodically refresh. I think providing such a mechnaism is useful.

> I think we need to separate the actual process how to send the
> PATH_TEST packets (i.e. path test process, what IP address try, and in
> which order, what information to use, what timers to use etc), from
> the packet format used for the PATH_TEST packets (i.e. separate
> PATH_TEST exchange, or any IKE packet). 

Agreed. The former is more implementation dependent and should
MOBIKE really say anything at all ? Also, note that which end does
the PATH_TEST has not been resolved yet i guess.

-mohan


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