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

 Pasi,

Couple of questions..

> >> 
> >> 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.
> 
As Jari pointed out, currently we don't know of a protocol that
the multihoming control module could use.

> - 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.
> 
Do you mean to say only IKEv2 can discover whether the path
works or not in a secure way ? i.e even if there is a protocol
discovered tomorrow that is not secure, it may not be sufficient.
Is that what you are trying to say ? Because you said "only IKEv2
message can tell that" ?

-thanks
mohan

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