Subject: Re: [Mobike] New issue 16: No packets from other end?

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 12 Oct 2004 13:04:42 -0700

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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 13 Oct 2004 00:12:01 +0200

=> there will be one: this is not the job of MOBIKE to specify one,
but this is the job of MULTI6 and MIP6.

Thanks

[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 12 Oct 2004 15:39:18 -0700

> but this is the job of MULTI6 and MIP6.
And for IPv4 ? How can MIP6 tell me that the (src, dst) pair is working
or not ?

-mohan

---

From: Francis Dupont <[email-masked]>
Date: Wed, 13 Oct 2004 00:46:28 +0200

=> and MIP4 (unfortunately either IPv4 multi-homing uses a PI address
or uses a MULTI6-like mechanism without specs...). Note for interesting
cases MIP6 includes MIP4 (this is why I've forgotten it).

Thanks

PS: the real issue is to do the job of MULTI6 in MOBIKE...
Mobility cases are well understood and even already implemented!
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Wed, 13 Oct 2004 07:42:55 +0300

> but this is the job of MULTI6 and MIP6.

Re: MIP6. There's been a draft or two about extending Mobile IPv6
to support multihoming (parallel addresses as opposed to serial ones).
However, this does not appear to be a work item in any of the current
IETF working groups related to Mobile IPv6.

Re: MULTI6. This is being worked on. But there are a couple of issues.
First, MULTI6 explicitly decided to handled the pure IPv6 problem
only. It seems that the solution their design team is thinking of
is going to work only for IPv6 without an easy extension to IPv4.
Secondly, since there are no detailed or official solution drafts
yet available for the failure detection part, its kind of hard to
tell whether it could be ripped out of MULTI6 and used for supporting
MOBIKE. Maybe. But probably more as an idea rather than relying
on what the MULTI6 module is telling MOBIKE. In fact, if you had
MULTI6 running and you were satisfied with the limitation to IPv6,
you would not need MOBIKE, right?

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Thu, 28 Oct 2004 12:09:49 +0200

=> you don't believe what you wrote (RFC 1918 is cited in your MULTI6 DT
draft :-).
My concern is clear: MOBIKE should not be a substitute of the whole OS,
even on a SG it can become the central task.

Regards

---

From: Jari Arkko <[email-masked]>
Date: Thu, 28 Oct 2004 13:13:43 +0300

> => you don't believe what you wrote (RFC 1918 is cited in your MULTI6 DT

What I write is my own opinion, and if I look at complicated
things like multihoming failure detection I don't want to look
only at IPv6. However, my understanding is still that the MULTI6
WG will only work on an IPv6 solution, so whatever is the final
MULTI6 RFC, it will not have IPv4 stuff...

> even on a SG it can become the central task.

I agree with this. But I guess the devil is in the details...

--Jari