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

[email protected] wrote:
> [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.

totally disagree with this particular statement. assuming the IP
stack is the lower layer (with might include MIP6/MULTI6), why
would MOBIKE be able to figure out something the IP stack couldnt?

UDP is a transport protocol on top of IP, right?

or am I missing the whole thing?

Vijay


> 
> - 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
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike