Subject: [Mobike] Re: Lack of packets from other end

From: "Bora Akyol" <[email-masked]>
Date: Tue, 14 Dec 2004 21:07:56 -0800

> 
> Message: 1
> Date: Thu, 09 Dec 2004 14:54:43 -0800
> From: Joe Touch <[email-masked]>
> Subject: Re: [Mobike] issue #16
> To: Tschofenig Hannes <[email-masked]>
> Cc: MOBIKE Mailing List <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Tschofenig Hannes wrote:
> | hi all,
> |
> | i guess we can close issue # 16:
> | "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/issue16.txt
> 
> Internet paths that are silent aren't problems, IMO. They're 
> just idle network paths.
> 
> This sounds like a job for a link layer, and I don't think 
> mobike needs to be a link layer.
> 
> Joe

I agree with Joe here. There are legitimate situations where there may
be no packets from the other end for a long period of time. We have DPD
to detect a dead peer. If a peer moves from one IP addr to another
without notifying the security gateway, I don't think it is the SG's job
to detect and recover from this.

Regards,

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

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 16 Dec 2004 21:14:01 -0500

> to detect and recover from this.

this is an somewhat akin to path mtu blackhole detection; inter-layer side 
channels could well allow an upper-layers repeated RTO to trigger a hunt
for a better path.  it's not the sort of thing which will be as immediately
effective as a link-down indication from L2 but it's not something that we 
should explicitly declare out of spec.

						- Bill

---

From: "Bora Akyol" <[email-masked]>
Date: Thu, 16 Dec 2004 20:04:09 -0800

Bill

Can you please expand on
"inter-layer side channels" and what you mean by that?

If a security gateway is supporting, say a million users,
what kind of processing do you envision by the SG to detect
an path change vs a client that has disappeared. Since mobile IP
is explicitly out of scope, all we have is the IP address of the end node,
other than DPD how can the SG detect a change of address of the client when
the client has moved to a different address.

I think for the first version of the MOBIKE specifications, we should focus
on getting something that is:

a) Scalable
b) Works
c) Simple

and do this quickly. This to me dictates a mostly client side notification
mechanism
with a very simple code base on the server, and a small state machine on the
client.

Next phase, we can focus on work that is combines faculties of link layer
with
the network layer. 

Regards,

Bora

> -----Original Message-----
> From: Bill Sommerfeld [mailto:[email-masked]] 
> Sent: Thursday, December 16, 2004 6:14 PM
> To: Bora Akyol
> Cc: [email-masked]
> Subject: Re: [Mobike] Re: Lack of packets from other end
> 
> > be no packets from the other end for a long period of time. We have 
> > DPD to detect a dead peer. If a peer moves from one IP addr 
> to another 
> > without notifying the security gateway, I don't think it is 
> the SG's 
> > job to detect and recover from this.
> 
> this is an somewhat akin to path mtu blackhole detection; 
> inter-layer side channels could well allow an upper-layers 
> repeated RTO to trigger a hunt for a better path.  it's not 
> the sort of thing which will be as immediately effective as a 
> link-down indication from L2 but it's not something that we