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

From: Jari Arkko <[email-masked]>
Date: Mon, 11 Oct 2004 13:14:20 +0300

Vijay Devarapalli wrote:

> I am not sure how you can do that. what if the application
> prefers "failing" to using an expensive link?
> 
> for example, lets assume my mobile device has a low bandwidth
> GPRS link (address IP1 on that link) and a high bandwidth WLAN
> link (address IP2 on that link). I have set it up so that my
> email is downloaded only when I connect to my Enterprise
> through a VPN connection when I have the WLAN link. if the
> WLAN link is not available, I dont want the email client to
> download email. lets assume I am in the middle of downloading
> email. I lose WLAN coverage. with your proposal, the MOBIKE
> protocol switches to using IP1. I dont want that.

I agree with your scenario.

> IMHO, I prefer "something in the Mobile Node" telling MOBIKE,
> "switch to using this address with this VPN GW". then a MOBIKE
> update should be sent. this is the model I had in my mind.
> 
> for "something in the Mobile Node" I had assumed DNA, MIP6,
> Multi6, new address configuration, default router change, etc...

I believe there's two levels of issue involved here. On
the first level, I think we have consensus that "something
in the mobile node" should be able to tell MOBIKE that
there's a new address or that a particular interface and
its addresses are no longer usable because the router went
down. I also think that we have consensus that at least most
of this is outside MOBIKE protocol and WG scope. They are
better handled in IPv6/DNA/DHC/MIP6 WGs. Finally, I believe
your policy issue about which interface should be used
is also at this level. And like I said, I agree with your
requirement that it should be possible to express such
policies. I think the others will agree too.

However, that's the part that the rest of the stack is
telling MOBIKE. The second level is what happens after
MOBIKE has been told something. For instance, lets say
that it has been told that there's two usable addresses
at this end and one at the other end; that's two possible
address pairs. Now we get a problem -- ESP tells IKE
that there's no packets, IKE attempts DPD which fails.
There's no information coming from IPv6/DNA/DHC/MIP6
(and presumably there will not be any information coming
soon either, because the DPD process took a while).
Now what? Are people saying that

   (1) Its okay for the MOBIKE peers to attempt recovery
       at the MOBIKE level by switching to another address
       pair.

   (2) Its not okay. MOBIKE/IKEv2/IPsec should fail and
       wait for the rest of the stack to inform when there's
       again an operational address.

       If problems on the path need to be handled, this would
       imply the development of a new, separate protocol for
       testing paths. Note that ICMP/TCP/app may already have
       told us of a problem with the current communications just
       as DPD did. But what we need is finding _another_ pair
       that works. No protocol that I know does that right now.
       Most of what we have in IPv6/DNA etc is focused on local
       issues, such as availability of the router.

(Assuming the "first level" is handled as explained earlier --
outside MOBIKE -- my personal preference would be #1.)

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

---

From: Francis Dupont <[email-masked]>
Date: Mon, 11 Oct 2004 21:01:01 +0200

In your previous mail you wrote:

   
=> this is true only because you take all your examples from
the mobility world, not from the multi-homing one which is
some years late compared to mobility. So IMHO your argument
is wrong and there will be an external mechanism which is able
to find another pair that works, ...

Regards

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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 11 Oct 2004 22:33:12 +0300

Hi Francis,

> some years late compared to mobility. So IMHO your argument

Lets see.. hmm... you are right that I was thinking too
much about the mobility world. But on the other hand,
do we have a multihoming protocol _right now_ that
does this? I think SCTP does it, but that would limit
the ability of MOBIKE to survive problems on the path
only if SCTP was used -- which seems pretty hard requirement
to me. Plus it wouldn't work with SGWs as far as I can
see, because there wouldn't be any SCTP in the endpoints.

I happen to know also that the MULTI6 protocol that is being
worked on includes will include a new protocol for this
purpose. But like SCTP, it only works as an integral
part of MULTI6, its not a standalone protocol. Plus
it doesn't work for IPv4, despite my requests to make
it so :-(

> to find another pair that works, ...

All I was saying is that there isn't one now :-) I forgot
SCTP, but OTOH that doesn't work for everything. And I'm
not aware of anyone developing a protocol that would cover
all the main requirements, and be usable together with
MOBIKE. But you are right -- this could change.

--Jari

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 11 Oct 2004 13:38:25 -0700

Jari,

> outside MOBIKE -- my personal preference would be #1.)

It looks like the options are not very good :-) If we choose (1) then we
end up doing what MULTI6 (or something else) within MOBIKE. If we
choose (2), we don't know who will provide the information to MOBIKE.
Perhaps, option (1) seems to make more sense in the immediate term as
there is no other protocol or effort going on now.

-mohan

---

From: "James Kempf" <[email-masked]>
Date: Mon, 11 Oct 2004 16:38:59 -0700

Mohan,

I can't see how having MOBIKE detect the failure and repair would work with
SCTP or TCP.

With SCTP, the transport layer is already managing failover, so having
MOBIKE try to do it too seems like it might result in some kind of conflict.
I don't know how SCTP is matched to IPsec now, but I'd like to know why that
isn't sufficient, since I assume it would allow the SCTP layer to switch to
whichever address it wanted with proper SA protection.

With TCP, the session is bound to the IP address, so if the address fails,
then the session must be terminated, by the TCP semantics. Having MOBIKE try
to change this would require some kind of cross-layer violation to tell TCP
to change.

As difficult and unpleasent as it seems, I can't see any way around just
letting the session fail if the address ceases to work. The IPSec layer
doesn't seem the right one to me to solve this problem.

            jak

---

From: Michael Richardson <[email-masked]>
Date: Mon, 11 Oct 2004 19:57:38 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "James" == James Kempf <[email-masked]> writes:
    James> With TCP, the session is bound to the IP address, so if the
    James> address fails, then the session must be terminated, by the
    James> TCP semantics. Having MOBIKE try to change this would require
    James> some kind of cross-layer violation to tell TCP to change.
  
  Typically, in RW scenarioes, an IP address is "extruded" through the
IPsec tunnel, and is bound to a virtual address on the end host.
  Think of this as being like MobileIP's Home-Address.

  So, if you fix the tunnel, then the stuff inside continues unchanged.

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 11 Oct 2004 18:37:49 -0700

hi Jari,

I dont agree with your conclusions. more below.

> soon either, because the DPD process took a while).

I dont agree with this statement. IMHO, if IPv6/DNA/DHC/MIP6 are
not able to figure out what happened, MOBIKE should just keep quiet.

>       again an operational address.

I think (2) is the way to go. I dont want MOBIKE making a
decision that conflicts with IPv6/DNA/DHC/MIP6/SCTP/whatever.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 11 Oct 2004 18:41:59 -0700

>   So, if you fix the tunnel, then the stuff inside continues unchanged.

MOBIKE should be used to fix the tunnel, but, in IMHO, MOBIKE shouldnt
decide when to fix the tunnel or what address to use to fix the tunnel.
the IP stack (which might include MIP6/DNA) should tell the MOBIKE
protocol what IP address to use to fix the tunnel.

Vijay

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
> Comment: Finger me for keys
> 
> iQCVAwUBQWsd8YqHRg3pndX9AQFFHwP9FNTJm2SMiEdqNNe2bpWPzK8nDNbJeLYQ
> 7qkEUBGYhngtSqmyFqBxnYvPWfOZWntMtATreEazF5PJuSlaLOVXT3YPXYPf9ht+
> 4V608AAQ90Ye92n2MlR/bsP93H4bWNASlJE3HJADp7+shSzDg0UiRlQULfMG6yGs
> W1tK8ngZs38=
> =atzH
> -----END PGP SIGNATURE-----

---

From: Michael Richardson <[email-masked]>
Date: Mon, 11 Oct 2004 23:13:14 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Vijay" == Vijay Devarapalli <[email-masked]> writes:

    >> Typically, in RW scenarioes, an IP address is "extruded" through
    >> the IPsec tunnel, and is bound to a virtual address on the end
    >> host.  Think of this as being like MobileIP's Home-Address.  So,
    >> if you fix the tunnel, then the stuff inside continues unchanged.

    Vijay> MOBIKE should be used to fix the tunnel, but, in IMHO, MOBIKE
    Vijay> shouldnt decide when to fix the tunnel or what address to use
    Vijay> to fix the tunnel.  the IP stack (which might include
    Vijay> MIP6/DNA) should tell the MOBIKE protocol what IP address to
    Vijay> use to fix the tunnel.

  That's fine.
  But the hint that address (A) works while (B) is now broken is an
attribute of the *outside* of the tunnel.

- --

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 11 Oct 2004 22:03:04 -0700

James,

> I can't see how having MOBIKE detect the failure and repair would work with
I was mainly assuming tunnel mode. The address change is concerned with the outer header
and not the inner header (i.e. traffic selector). I thought we are not concerned about
transport mode at all. The charter says this clearly.

> whichever address it wanted with proper SA protection.
RFC 3554 is the attempt to map multiple addresses to a single SA. Having said that,
i don't know what MOBIKE is planning to provide. The charter does talk about
modification of SCTP endpoints without renegotiating the SA.

The charter says:

     An explicit non-goal is the construction of a fully fledged mobility
     protocol. In particular, the WG shall NOT develop mechanisms for the
     following functions:

          o Hiding of mobility from transport layer protocols or applications
            (beyond what already exists through the use of the tunnel mode). In
            this respect MOBIKE is different from Mobile IP, HIP, and other
            mobility protocols.

Though SCTP is a transport layer protocol, it is included for the multi-homing
part i guess.

> doesn't seem the right one to me to solve this problem.
Correct. But this affects only transport mode.

-mohan