RE: Re: Lack of packets from other end

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 protected]] 
> Sent: Thursday, December 16, 2004 6:14 PM
> To: Bora Akyol
> Cc: [email protected]
> Subject: Re: [Mobike] Re: Lack of packets from other end
> 
> On Wed, 2004-12-15 at 00:07, Bora Akyol wrote:
> 
> > 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.
> 
> 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
>