Re: New issue 16: No packets from other end?

 In your previous mail you wrote:

   >    I think MOBIKE should get use and try to get as much information from
   >    outside as possible, but in the end it still needs to test the
   >    possible address pairs by itself to get positive feedback that the
   >    address pair works.
   >    
   > => this is (check the address pair works) the job of the IPsec module,
   > not MOBIKE, at the exception of primary peer addresses for IKE messages.
   
   Let me try to understand this statement better. Are you saying
   that testing an address pair is the job of the ESP/AH module,

=> this one: the idea is that the important point is the address pair
works for the service (which is IPsec, IKE is its control).

   or that it belongs to the IKEv2 functionality already specified
   (even without MOBIKE extension)?
   
=> DPD is a useful but already existing mechanism. IMHO it is not
really enough in this case.

   I think you must mean the latter. Here's why: the current IKEv2
   approach to this appears to be DPD, which works through IKEv2
   messages, right? Or am I missing something?
   
   (Certainly the lack of ESP packets might be a HINT that something
   is wrong, but you wouldn't know if it was due to lack of need
   to send packets until you try with DPD.)
   
=> IPsec and IKE packets are the "same" only with UDP encapsulation...
so IMHO a direct control (here some kind of DPD) in the IPsec engine
is useful too, and even without mobike (i.e., problems should be detected,
mobike is here only to provide a way to fix them).

Regards

[email protected]