Re: issue 11 -- window size

Mohan Parthasarathy writes:
>  > > 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 ? 

So to create overlay IKE SA message IDs using the same SPIs, but
separate flag to specify that you these messages are not constrained
by the window of normal message IDs? Yes, that would also 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 ?

Most of those options, could be used by most of the protocols. There
is nothing that exactly ties in the PATH_TEST message format and the
actual mobike protocol. Thats why we are now trying to decide which
one to use.

> Ok, the other end knows that it is "DPD path" test, so just reply
> and don't affect the SAs.

Yes. Of course it need to reply to the DPD packets all the time, and I
think we do not want to tie in path test and moving of SAs, i.e. in my
example I used separate information exchange sending notification
which actually made the changes to the SA addresses. I.e. the change
operation is explicitly done, instead of implictly happening after we
notice that path changed.

IKEv2 NAT-T does the implicit path changing, i.e. every time the
address changes then addresses of SAs are updated. I think mobike
should do explicit updating, but that is one option we need to decide
too. 

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

I think we need to give at least some implementation hints or
description how it could be done, so we have some kind of common way
of doing it. Exact details what information is used etc can be left to
implementations, as different implementations have different hints
available for them. 

> Also, note that which end does the PATH_TEST has not been resolved
> yet i guess.

That mostly depends on other questions, like if we do initiator
decides then he is the one doing path tests etc...
-- 
[email protected]