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

From: <[email-masked]>
Date: Mon, 16 Aug 2004 11:23:04 -0400

Hi Pasi,

Situations where traffic being sent expects a response
from the other end in a reasonable time, can give some
indication of network/path failures, though not an 
absolute indication. But just saying that "No packets 
from the other end in some amount of time" is an indicative
of network/path failure may not be a correct statement.

We will have to explicitly say, that if certain part of the
protocol, say an IKE message does not get response in a
certain amount of time, we initiate change of address. 
Another possibility could be the keepalives, which shall be
needed for the NAT case anyway, could be used as an indication
of network/path failures. Lack of keepalive could be a
trigger for MOBIKE change of address notification.

I agree we should try to recover from as many failures/changes
as possible without making the protocol unreasonably complex. I
think use of keepalives, which are needed anyway, for this purpose
should not make the protocol any more complex than it already is.

>From the title of the issue, it seemed we are trying to proactively
solve network failure recovery.

I think we are in agreement. This sounds reasonable to me. I 
guess, then we will have to understand Francis' objection to 
such failure recovery.

Best,
Atul

> -----Original Message-----
> From: Eronen Pasi (Nokia-NRC/Helsinki) 
> Sent: Monday, August 16, 2004 9:42 AM
> To: Sharma Atul (Nokia-ES/Boston); [email-masked]
> Subject: RE: [Mobike] New issue 16: No packets from other end?
> 
> 
> Hi Atul,
> 
> My impression was that the main reason we are adding 
> multihoming support to IKEv2 is to recover from failures 
> (since load balancing is explicitly beyond the scope). 
> 
> I think that restricting ourselves to those network failures 
> where we get an explicit "link down" signal will seriously 
> limit the usefulness of the protocol's multihoming features.
> (For instance, the multihoming features of SCTP don't
> have that kind of restriction.)
> 
> Best regards,
> Pasi
> 
> > -----Original Message-----
> > From: [email-masked]
> > Sent: Monday, August 16, 2004 3:33 PM
> > To: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
> > Subject: RE: [Mobike] New issue 16: No packets from other end?
> > 
> > 
> > Thanks Passi,
> > 
> > ....for the explanation. I think in that case you are trying
> > to solve network failure recovery inside the MOBIKE protocol.
> > 
> > I think Francis and someone else on the list commented such
> > functionality should probably be outside the MOBIKE protocol
> > specification.
> > 
> > MOBIKE's mandate, in my opinion, is to notify the "other end"
> > of the change in address or plurality of addresses due to 
> > mobility or multihoming using IKE mechanism (information 
> > exchange). Trying to solve a general problem within MOBIKE,
> > may complicate MOBIKE protocol unnecessarily. Network failure
> > recovery (without notifications) should be solved elsewhere
> > IMHO.
> > 
> > Best,
> > Atul
> > 
> > > -----Original Message-----
> > > From: Eronen Pasi (Nokia-NRC/Helsinki) 
> > > Sent: Monday, August 16, 2004 7:38 AM
> > > To: Sharma Atul (Nokia-ES/Boston); [email-masked]
> > > Subject: RE: [Mobike] New issue 16: No packets from other end?
> > > 
> > > 
> > > 
> > > Hi Atul,
> > > 
> > > The other end could be a mobile host or SGW, depending 
> > > on your point of view.
> > > 
> > > The issue is what to do if we have not received a "link 
> > > down" signal from layer 2 (or somewhere), but we don't 
> > > get any responses (to IKEv2 requests) from the other end 
> > > either. In this situation,  should we just close the 
> > > connection, or "somehow" trigger MOBIKE to change to 
> > > some other address(es)? 
> > > 
> > > (Some details of the "somehow" part will be beyond 
> > > the scope of the MOBIKE specification, but probably  
> > > something needs to be said to ensure interoperability.)
> > > 
> > > Best regards,
> > > Pasi
> > > 
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > Sent: Friday, August 13, 2004 5:40 PM
> > > > To: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
> > > > Subject: RE: [Mobike] New issue 16: No packets from other end?
> > > > 
> > > > I needed some clarifications from MOBIKE veterans, before 
> > > > expressing an opinion:
> > > > 
> > > > What is the "other end" here? The mobile host? or the 
> > > > multihoming SGW?
> > > > 
> > > > Who initiates the MOBIKE protocol? I would guess:
> > > >    (1) a mobile host after the move, needs to notify the 
> > > >        remote SGW of its new address.
> > > >    (2) a multihoming SGW, upon detecting that one of its 
> > > >        interfaces (which was used to contact the mobile host)
> > > >        is down and it needs to notify the mobile host of its
> > > >        new interface address to be used.
> > > > 
> > > > Are there any other scenarios of how MOBIKE can be initiated? 
> > > > When would we use the information that there is "lack 
> of packets 
> > > > from the other end", to initiate the MOBIKE protocol?
> > > > 
> > > > Thanks,
> > > > Atul
> > > > 
> > > > > -----Original Message-----
> > > > > From: [email-masked] 
> > > > > [mailto:[email-masked]]On
> > > > > Behalf Of ext 
> > > > > Sent: Thursday, August 12, 2004 9:01 AM
> > > > > To: [email-masked]
> > > > > Subject: [Mobike] New issue 16: No packets from other end?
> > > > > 
> > > > > 
> > > > > I've created a new issue in the issue list:
> > > > > 
> > > > >    "Can the protocol recover from situations where the only 
> > > > >    sign of problems is lack of packets from the other end?"
> > > > > 
> > > > >    (http://www.vpnc.org/ietf-mobike/issues.html)
> > > > > 
> > > > > Many people at the WG meeting expressed opinions that this 
> > > > > should be handled somehow (in addition to handling e.g. 
> > > > > link-down triggers from layer 2, or something similar).
> > > > > 
> > > > > So far, I do not remember anyone saying that the protocol
> > > > > does not need to handle this situation. But comments
> > > > > are welcome.
> > > > > 
> > > > > 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: Tero Kivinen <[email-masked]>
Date: Tue, 17 Aug 2004 09:54:41 +0300

> should not make the protocol any more complex than it already is.

Note, that NAT-T keepalives are not authenticated, and MUST NOT be
used to any other purpose than to keep the NAT mapping up. They MUST
NOT be used to give any indication whether the other end is up or not.
The sender of the keepalives, can stop sending them at any time, if it
detects that NAT does not need them, or it can put the TTL low enough
so that they never reach the final IKE destination, but do go through
the NAT. And the sender do not send keepalives if it has sent any ESP
packets lately to the other end, i.e the ESP packets also acts as
keepalives, the specific keepalive packets are only used if there is
no other traffic going through. 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike