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

[email protected] writes:
>> 
>> BTW, if we were adding MOBIKE to IKEv1, nothing extra would be 
>> needed in the protocol to allow hosts to handle this "no packet 
>> from other end" case; the R-U-THERE dead peer detection messages 
>> [RFC3706] would be enough.
>>    
>> But currently it seems (to me at least) that in IKEv2, the ability 
>> to send some kind of R-U-THERE/Hello/Ping/Heartbeat/Path test
>> messages outside the IKEv2 window would be necessary, or at 
>> would simplify the protocol considerably. (And since we decided 
>> not to assume full connectivity, something like that message may 
>> be needed anyway.)
>    
> 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)

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

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

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

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

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

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

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

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.

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

Best regards,
Pasi