RE: issue 11 -- window size

> -----Original Message-----
> From: Stephane Beaulieu [mailto:[email protected]] 
> Sent: Thursday, March 31, 2005 10:48 AM
> To: 'Geoffrey Huang'; 'Paul Hoffman'; 'Bill Sommerfeld'; 'Jari Arkko'
> Cc: [email protected]
> Subject: RE: [Mobike] issue 11 -- window size
> 
> Right, but we write the code for the implementation don't we? :)
> 
> So, a mobike capable IKEv2 implementation *could* exceed the 
> peer's window ONLY for mobike msgs, and choose NOT to view a 
> lack of response as a failure on these messages.  

Then the DPD mechanism wouldn't ever work with MOBIKE.  Suppose the peer's
window size is N, and we decide to go ahead and exceed it.  We send a delete
out for message N+1.  We don't get a response; how long do we continue to
retransmit this delete message?

-g

> The way I see it, mobike is kind of a special case, since 
> when an interface change happens, we'll never know for sure 
> if the peer did respond to a previous message, but we didn't 
> get it, or if the previous request is still sitting on the 
> peer's queue.  We do know that we can't retransmit our 
> request (since we haven't picked a new interface yet).
> 
> Stephane. 
> 
> > -----Original Message-----
> > From: Geoffrey Huang [mailto:[email protected]]
> > Sent: Thursday, March 31, 2005 1:25 PM
> > To: [email protected]; 'Paul Hoffman'; 'Bill Sommerfeld'; 'Jari 
> > Arkko'
> > Cc: [email protected]
> > Subject: RE: [Mobike] issue 11 -- window size
> > 
> > Yes, I suppose you could just keep retransmitting your messages.  
> > However, I would assume that most implementations would 
> view a failure 
> > to respond as a sign that the peer might be dead.  Either the 
> > implementation would just delete the SA or (window 
> permitting), kick 
> > off DPD.  Since the window size is already reached (and 
> breached), you 
> > won't be getting any response from the peer for the DPD messages.  
> > Essentially, this would still result in the deletion of the IKE SA.
> > 
> > -g
> > 
> > > -----Original Message-----
> > > From: Stephane Beaulieu [mailto:[email protected]]
> > > Sent: Thursday, March 31, 2005 9:49 AM
> > > To: 'Paul Hoffman'; 'Geoffrey Huang'; 'Bill Sommerfeld';
> > 'Jari Arkko'
> > > Cc: [email protected]
> > > Subject: RE: [Mobike] issue 11 -- window size
> > > 
> > > Is there really a point of reserving.  I mean, what's the
> > peer going
> > > to do if you exceed the window? (other than complain you're
> > violating
> > > the RFC :).
> > > The peer will silently drop it until it's finished with
> > another one,
> > > right.
> > > So what !  I can just keep transmitting my mobike
> > message(s) until the
> > > peer has a chance to process it and respond, right?
> > > 
> > > Stephane.
> > > 
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: [email protected]
> > > > [mailto:[email protected]] On Behalf Of Paul Hoffman
> > > > Sent: Thursday, March 31, 2005 10:44 AM
> > > > To: Geoffrey Huang; 'Bill Sommerfeld'; 'Jari Arkko'
> > > > Cc: [email protected]
> > > > Subject: RE: [Mobike] issue 11 -- window size
> > > > 
> > > > At 9:51 PM -0800 3/30/05, Geoffrey Huang wrote:
> > > > >So it needs to
> > > > >split this between "regular" IKE messages and MOBIKE messages?
> > > > 
> > > > Not "split", but "allow enough extra for MOBIKE".
> > > > 
> > > > >I prefer your earlier suggestion of reserving one or two
> > > message IDs
> > > > >from the window for mobility purposes.  Consider a roaming
> > > > client that
> > > > >gets a notify from a security gateway (SGW) saying the
> > > SGW's window
> > > > >size is 5.  The client should know that it's capable of
> > > mobility and
> > > > >consequently reserve a message ID for MOBIKE messages.  Just
> > > > because a
> > > > >peer sends a notification about a window size doesn't
> > mean that an
> > > > >implementation needs to fill up the window.
> > > > 
> > > > That sounds good. The question is: how many should we 
> suggest to 
> > > > reserve?
> > > > 
> > > > --Paul Hoffman, Director
> > > > --VPN Consortium
> > > > _______________________________________________
> > > > Mobike mailing list
> > > > [email protected]
> > > > https://www.machshav.com/mailman/listinfo.cgi/mobike
> > > > 
> > > 
> > 
>