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

 In your previous mail you wrote:

   > Pasi, I understand your reasonning but not its conclusion.
   
   I'm not totally sure about the conclusion myself, but I'll try 
   to clarify my reasoning a bit. Consider the following situation:
   
   - Both peers (A and B) have several addresses (A1,A2,...An,
     B1,B2,...Bn)
   
=> you assume a peer address set management (OK).

   - We don't have full connectivity: there are some (i,j) 
     for which using Ai,Bj does not provide connectivity  
     between the IKEv2 endpoints (that is, IKEv2 
     implementations running on hosts A and B).
   
=> some kind of loose pairing is needed if the knowledge
is a priori (OK but this can be a strong assumption).

   - Host A receives some kind of indication (beyond the scope 
     of MOBIKE) that its current address (say, A1) is likely to 
     stop working soon.
   
=> OK

   - Since we don't have full connectivity, A's "mobility and 
     multihoming control module" would like to find the best 
     working (Ai,Bj) before the current one stops working.
   
=> OK (usually the module tries to get this knowledge as soon
as possible but there is no general solution to provide this).

   - In general, lower-layer mechanisms cannot tell whether pair
     (Ai,Bj) provides connectivity between the IKEv2 endpoints:
     only an IKEv2 message exchange can tell that.
   
=> I disagree: the lower-layer here is the IP layer, and
it is the layer which can get the information. I don't
believe in IP connectivity without UDP connectivity even
this is possible in theory.

   - If we have a separate R-U-THERE message (without window
     size restrictions), A's "mobility and multihoming control 
     module" could just ask the "MOBIKE module" to try whether
     some (Ai,Bj) works without worrying about interfering with
     anything else IKEv2 might be doing.
   
=> ask the MOBIKE module should be only an option.

   - We can't in general just send a new IKEv2 informational 
     exchange request, because there might be a pending
     request already (and this is the crucial difference 
     to IKEv1). And just waiting until we get a reply to 
     the pending request does not work either if getting
     a reply depends on us doing something before that.
   
=> this is why I said "should be only an option": the R-U-THERE
of IKEv2 is not well suited for parallel probing because of
the window issue. IMHO the real problem is that probes should
be at the IP layer not at the IKEv2 layer: one tries to probe
the IP paths, not the peer IKEv2.

   - In some earlier protocol sketch I suggested just sending
     the most recent IKE request as a test packet: the other 
     end will retransmit its reply if that (Ai,Bj) works.
     But it turned out that this can in fact interfere
     with other functionality, such as return routability 
     checks and "NAT prevention" payloads in some circumstances 
     (if the original request packet got lost).
   
=> another issue but IMHO the return routability checks and
NAT prevention stuff should be done before. Of course this is
true only in an ideal world.

   It's possible that this icould be solved by some other
   means than introducing a "non-window-restricted" message...
   but it might be the simplest solution.
   
=> we can use the fact the peer addresses are not part (if
one doesn't put them inside explicitely) of IKE messages,
i.e., the same request can be sent using different addresses
and each eventual reply has the addresses reversed.

   (In particular, I'm not happy with the idea of assuming --- 
   totally contrary to the end-to-end principles --- that the 
   "mobility and multihoming module" knows or can figure out 
   connectivity between IKEv2 endpoints without sending IKEv2
   messages.)  
   
=> IMHO the problem is about the "connectivity" term: it can be
either IP path availability or peer IKEv2 live check. The dead
peer detection is explicitely about the second case but what
we want here is the first one.

Thanks

[email protected]