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

James,

  
> I can't see how having MOBIKE detect the failure and repair would work with
> SCTP or TCP.
> 
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.

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

> 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.
> 
Correct. But this affects only transport mode.

-mohan

>             jak
> 
> 
> ----- Original Message ----- 
> From: "Mohan Parthasarathy" <[email protected]>
> To: <[email protected]>; "Vijay Devarapalli" <[email protected]>
> Cc: <[email protected]>; <[email protected]>
> Sent: Monday, October 11, 2004 1:38 PM
> Subject: Re: [Mobike] New issue 16: No packets from other end?
> 
> 
> > Jari,
> >
> > > > 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.)
> >
> > 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
> >
> > >
> > > --Jari
> > > _______________________________________________
> > > Mobike mailing list
> > > [email protected]
> > > https://www.machshav.com/mailman/listinfo.cgi/mobike
> > _______________________________________________
> > Mobike mailing list
> > [email protected]
> > https://www.machshav.com/mailman/listinfo.cgi/mobike
> >
> 
> 
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike