Subject: [Mobike] issue 11 -- window size

From: Jari Arkko <[email-masked]>
Date: Wed, 30 Mar 2005 17:30:23 +0300

This issue is about the window size. Mobike needs to be able to
send multiple messages, given that a regular IKEv2 exchange
may be in progress when we suddenly change our IP address.
The question is whether we should expect IKEv2 implementations
to support window size greater than 1, or if Mobike's own
exchanges are in some sense outside the regular IKEv2
window (as proposed in Pasi's MOPO protocol).

The background information we got in the meeting was that
in the IKEv2 bakeoff many implementors did not have
support for larger than 1 window sizes.

So we could either require a larger window size or do MOBIKE
exchanges outside the window. I did not sense a conclusion
in the meeting about this, but on the other hand I'm not sure
if people care about this issue very deeply. For the purpose
of making progress, let me propose one approach. If the
decision was "do it outside the window", would people have
problems with that?

--Jari

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

---

From: "Stephane Beaulieu" <[email-masked]>
Date: Wed, 30 Mar 2005 15:41:29 -0500

I think we should expect implementations to support a window size > 1.  I
think eventually people will need to do this for things like DPDs, DELETEs,
Notifies, rekey overlaps, etc... to work properly.

Remember that the bakeoff implementations haven't been deployed yet.  They
haven't suffered the consequences of a very small window yet.

Stephane.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jari Arkko
> Sent: Wednesday, March 30, 2005 9:30 AM
> To: [email-masked]
> Subject: [Mobike] issue 11 -- window size
> 
> 
> This issue is about the window size. Mobike needs to be able 
> to send multiple messages, given that a regular IKEv2 
> exchange may be in progress when we suddenly change our IP address.
> The question is whether we should expect IKEv2 
> implementations to support window size greater than 1, or if 
> Mobike's own exchanges are in some sense outside the regular 
> IKEv2 window (as proposed in Pasi's MOPO protocol).
> 
> The background information we got in the meeting was that in 
> the IKEv2 bakeoff many implementors did not have support for 
> larger than 1 window sizes.
> 
> exchanges outside the window. I did not sense a conclusion in 
> the meeting about this, but on the other hand I'm not sure if 
> people care about this issue very deeply. For the purpose of 
> making progress, let me propose one approach. If the decision 
> was "do it outside the window", would people have problems with that?
> 
> --Jari
> 
>

---

From: "Geoffrey Huang" <[email-masked]>
Date: Wed, 30 Mar 2005 12:46:48 -0800

I agree.  I think it's reasonable to expect a window size > 1.

-g 

> [mailto:[email-masked]] On Behalf Of Stephane Beaulieu
> Sent: Wednesday, March 30, 2005 12:41 PM
> To: 'Jari Arkko'; [email-masked]
> Subject: RE: [Mobike] issue 11 -- window size
> 
> I think we should expect implementations to support a window 
> size > 1.  I think eventually people will need to do this for 
> things like DPDs, DELETEs, Notifies, rekey overlaps, etc... 
> to work properly.
> 
> Remember that the bakeoff implementations haven't been 
> deployed yet.  They haven't suffered the consequences of a 
> very small window yet.
> 
> Stephane.
> 
> > This issue is about the window size. Mobike needs to be 
> able to send 
> > multiple messages, given that a regular IKEv2 exchange may be in 
> > progress when we suddenly change our IP address.
> > The question is whether we should expect IKEv2 implementations to 
> > support window size greater than 1, or if Mobike's own 
> exchanges are 
> > in some sense outside the regular
> in the IKEv2 
> > bakeoff many implementors did not have support for larger than 1 
> > window sizes.
> > 
> > So we could either require a larger window size or do 
> MOBIKE exchanges 
> > outside the window. I did not sense a conclusion in the 
> meeting about 
> > this, but on the other hand I'm not sure if people care about this 
> > issue very deeply. For the purpose of making progress, let 
> me propose 
> > one approach. If the decision was "do it outside the window", would 
> > people have problems with that?
> > 
> > --Jari
> > 
> >

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 30 Mar 2005 16:07:41 -0500

> I agree.  I think it's reasonable to expect a window size > 1.

the issue is a bit more subtle than that: if mobike mobility requests
(of whatever form) occupy ike request sequence space, then in order to
avoid deadlocking during a move while there are other outstanding
requests, mobike implementations will need to reserve at least the
"last" request window slot for those requests at all times, effectively
reducing the window at all other times by at least one request.

---

From: "Geoffrey Huang" <[email-masked]>
Date: Wed, 30 Mar 2005 13:21:47 -0800

Hm...interesting.  I still think it's reasonable to expect a window size >
1.

-g 

> From: Bill Sommerfeld [mailto:[email-masked]] 
> Sent: Wednesday, March 30, 2005 1:08 PM
> To: Geoffrey Huang
> Cc: [email-masked]; 'Jari Arkko'; [email-masked]
> the issue is a bit more subtle than that: if mobike mobility 
> requests (of whatever form) occupy ike request sequence 
> space, then in order to avoid deadlocking during a move while 
> there are other outstanding requests, mobike implementations 
> will need to reserve at least the "last" request window slot 
> for those requests at all times, effectively reducing the 
> window at all other times by at least one request.
> 
> 
> 
>

---

From: "Stephane Beaulieu" <[email-masked]>
Date: Wed, 30 Mar 2005 16:37:03 -0500

That's a good point.

This is only the case though if you assume that a mobility request should
have a higher priority than a 'normal' request.  That normal request, if
deadlocked due to mobility change, I would think would eventually time out,
thus clearing up the window for the mobility request to get through.  Of
course, that would cause loss of connectivity for the length of the time
out, but then again, maybe that's the price you pay for having a small
window.

Perhaps the answer is that you don't timeout.  Retransmit forever.  But then
the question becomes what do you do when a peer doesn't respond to a
request.  What do you do if the window is full.  Can't send a DEL, or a DPD.
Are you supposed to just retransmit forever, or silently drop the
connection?

Stephane.

> Sent: Wednesday, March 30, 2005 4:08 PM
> To: Geoffrey Huang

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 30 Mar 2005 16:45:01 -0500

On Wed, 2005-03-30 at 16:37, Stephane Beaulieu wrote:
> thus clearing up the window for the mobility request to get through. 

it appears that IKEv2 doesn't work that way.  quoting from
draft-ietf-ipsec-ikev2-17.txt:

   An IKE endpoint MUST NOT exceed the peer's stated window size for
   transmitted IKE requests. In other words, if the responder stated its
   window size is N, then when the initiator needs to make a request X,
   it MUST wait until it has received responses to all requests up
   through request X-N.

in other words, if you don't hear back from the peer at all, you can
tear down the IKE association but you can't abandon a request in
progress and keep going forward through the sequence space.

						- Bill

---

From: "Geoffrey Huang" <[email-masked]>
Date: Wed, 30 Mar 2005 13:57:26 -0800

Tero pointed this out to me at the bakeoff.  Suppose your peer's window size
is 1; you send him a DPD (which he doesn't respond to).  Eventually, you
delete your SA, but you can't send him a request to do the same.  The peer
will eventually figure it out, hopefully.

-g 

> Sent: Wednesday, March 30, 2005 1:45 PM
> To: [email-masked]
> Cc: 'Geoffrey Huang'; 'Jari Arkko'; [email-masked]
> > This is only the case though if you assume that a mobility request 
> > should have a higher priority than a 'normal' request.  That normal 
> > request, if deadlocked due to mobility change, I would think would 
> > eventually time out, thus clearing up the window for the 
> mobility request to get through.
> 
> in other words, if you don't hear back from the peer at all, 
> you can tear down the IKE association but you can't abandon a 
> request in progress and keep going forward through the sequence space.
> 
> 						- Bill
>

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 30 Mar 2005 14:29:48 -0800

> decision was "do it outside the window", would people have
When the message is sent outside the window, is it still protected
with the IKE SA or not ? 

Even if the window size is greater than 1, the window may be filled
up with previous messages. So, we are back to the same problem, right ?

-mohan

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 30 Mar 2005 17:41:15 -0500

> When the message is sent outside the window, is it still protected
ikev2 says you MUST NOT send a message outside the window.

> up with previous messages. So, we are back to the same problem, right ?

effectively, yes, unless you prereserve some chunk of the window for
last-minute mobility.

(I suspect that we may be better off adding a distinct sequence space
for mobility requests, viewed as a slightly lower layer than the
existing phase 2 requests).

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 30 Mar 2005 17:56:40 -0500

On Wed, 2005-03-30 at 09:30, Jari Arkko wrote:
> For the purpose

(I'm reading mail out of order)

I don't have a problem with that. 

One encoding which makes this clear would be to allocate a new IKEv2
Exchange Type and specify that it has a distinct Message ID space
distinct from the space used by the existing four types (see section 3.1
of draft-ietf-ipsec-ikev2-17.txt).  

(An alternative would be to grab one or more of the Flags bits, but they
are somewhat more scarce..)

					- Bill

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 30 Mar 2005 15:28:10 -0800

> ikev2 says you MUST NOT send a message outside the window.
My understanding is that in Pasi's MOPO protocol, the PATH_TEST
message is sent outside the window and also outside the IKE SA. (Perhaps
someone could clarify that). Once you know the new PATH, retransmit
all the messages in the existing window in the new PATH. Then, change
an explicit PATH_CHANGE message. In this method, you needed
only the *PATH_TEST* message outside the window (and also
outside the SA).  MOBIKE messages itself was sent within the window.
Jari's question was about all MOBIKE messages i guess. If all of them
needs to be sent outside the window, then defining its own message-id
space makes sense i guess. 

> existing phase 2 requests).
Yes,  MOBIKE can define its own space and the message-id can be
carried in the payload itself i guess.

-mohan

---

From: "Stephane Beaulieu" <[email-masked]>
Date: Wed, 30 Mar 2005 21:10:46 -0500

Thanks for the clarification.

Given this, then I'm wondering how the connectivity check would work when
we're trying to determine which pair of interfaces to switch to.

Presumably it goes like this...  

Say PeerA, and PeerB, both with a window size = 2.

PeerA (A1, A2) <--> PeerB (B1, B2, B3)

A1 <--> B1 stops working (more precisely, some network devices near A1 stops
working)

1 - PeerA sends a DPD (thus occupying 1 window slot)
2 - PeerA retransmits DPD a few times.
3 - PeerA sends a connectivity check A1->B2 (thus occupying a 2nd window
slot)
4 - PeerA wants to send a connectivity check A1->B3, but has no window room
left.

Question:
Would the connectivity check just be a replay of the DPD in 1? (thus
re-using the window slot?) or would it occupy a new window slot?

Stephane.

> Sent: Wednesday, March 30, 2005 4:45 PM
> To: [email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Thu, 31 Mar 2005 07:59:00 +0300

Hi Mohan,

>When the message is sent outside the window, is it still protected
Yes, it should be.

>up with previous messages. So, we are back to the same problem, right ?
Potentially yes, see my next post.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 31 Mar 2005 08:03:15 +0300

>re-using the window slot?) or would it occupy a new window slot?
That's a good question. We have to prepare also for the
possibility that more than a single change of connectivity
happens very fast. So if we have filled the window up with,
say, N-2 requests already, does that mean that we are
limited to at most 2 MOBIKE related requests at this time,
whether those are due to trying multiple addresses or
due to yet another change in connectivity?

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 31 Mar 2005 08:04:59 +0300

>of draft-ietf-ipsec-ikev2-17.txt).  
This would work for me. But I'd still like to understand
what happens when we have to do several MOBIKE
requests in this new space before we get an answer from
the peer, are we bounded by some upper limit, or can we
do any number of operations?

--Jari

---

From: "Geoffrey Huang" <[email-masked]>
Date: Wed, 30 Mar 2005 21:51:51 -0800

> [mailto:[email-masked]] On Behalf Of Bill Sommerfeld
> Sent: Wednesday, March 30, 2005 2:57 PM
> To: Jari Arkko
> Cc: [email-masked]
> Subject: Re: [Mobike] issue 11 -- window size
> 
> decision was 
> > "do it outside the window", would people have problems with that?
> 
> One encoding which makes this clear would be to allocate a 
> new IKEv2 Exchange Type and specify that it has a distinct 
> Message ID space distinct from the space used by the existing 
> four types (see section 3.1 of draft-ietf-ipsec-ikev2-17.txt).  

I'm still considering this, but at the moment, I don't like this.  Granted,
it's unlikely two IKE peers would ever exhaust the message ID space, so
reserving a portion of this space shouldn't cause us to run out of "regular"
IKEv2 message IDs.  However, an implementation might set its window size to
5 because it really does only want to handle 5 messages at a time.  So now
what if we have this distinct message ID space, and the implementation needs
to consider the fact that it can only handle 5 messages.  So it needs to
split this between "regular" IKE messages and MOBIKE messages?

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.

-g

> (An alternative would be to grab one or more of the Flags 
> bits, but they are somewhat more scarce..)
> 
> 					- Bill
> 
>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 31 Mar 2005 07:43:54 -0800

At 9:51 PM -0800 3/30/05, Geoffrey Huang wrote:
>So it needs to

Not "split", but "allow enough extra for MOBIKE".

>about a window size doesn't mean that an implementation needs to fill up the

That sounds good. The question is: how many should we suggest to reserve?

--Paul Hoffman, Director
--VPN Consortium

---

From: "Geoffrey Huang" <[email-masked]>
Date: Thu, 31 Mar 2005 07:57:22 -0800

> From: Paul Hoffman [mailto:[email-masked]] 
> Sent: Thursday, March 31, 2005 7:44 AM
> To: Geoffrey Huang; 'Bill Sommerfeld'; 'Jari Arkko'
> Cc: [email-masked]
> >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.
> 

Wouldn't one be sufficient for the address update notification?

-g

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 31 Mar 2005 11:02:21 -0500

On Thu, 2005-03-31 at 10:43, Paul Hoffman wrote:
> The question is: how many should we suggest to reserve?

we have no idea how many will be needed until we design the rest of the
protocol.
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 31 Mar 2005 09:22:40 -0800

Why are we reserving from the existing space ? Why not have its own space ? 

-mohan

---

From: "Geoffrey Huang" <[email-masked]>
Date: Thu, 31 Mar 2005 09:35:06 -0800

Because then you would need to keep track of too many lists of messages.
Currently, we already need to keep track of the window of messages I send to
the peer, as well as a window of messages the peer sends to us.  If we use a
separate message ID space, we would need to keep those two windows, and on
top of that, we'd need to keep another 2 just for the MOBIKE exchange.

-g 

> [mailto:[email-masked]] On Behalf Of Mohan Parthasarathy
> Sent: Thursday, March 31, 2005 9:23 AM
> To: Bill Sommerfeld; Paul Hoffman
> Cc: 'Jari Arkko'; [email-masked]

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 31 Mar 2005 09:37:30 -0800

> do any number of operations?
Good question. If the other end has 10 addresses and currently
now reachable at only one address, we might have to try at least
9 addresses i.e 9 or more messages to find out the working path.
I don't know how it will work if it is based on the current window
scheme of IKEv2. If i don't get a response for a request, i need
to retransmit a different message (using different address) with the
same message-id or a new message with a new message-id (which
means any number of operations) till a working pair is obtained.
Am i missing something..Perhaps that's why the path-test message
should not be constrained by the window ?

-mohan

---

From: "Stephane Beaulieu" <[email-masked]>
Date: Thu, 31 Mar 2005 12:48:40 -0500

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.

> [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Thursday, March 31, 2005 10:44 AM

---

From: "Geoffrey Huang" <[email-masked]>
Date: Thu, 31 Mar 2005 10:24:38 -0800

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

> From: Stephane Beaulieu [mailto:[email-masked]] 
> Sent: Thursday, March 31, 2005 9:49 AM
> To: 'Paul Hoffman'; 'Geoffrey Huang'; 'Bill Sommerfeld'; 'Jari Arkko'
> Cc: [email-masked]

---

From: "Stephane Beaulieu" <[email-masked]>
Date: Thu, 31 Mar 2005 13:47:58 -0500

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.  

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. 

> From: Geoffrey Huang [mailto:[email-masked]] 
> Sent: Thursday, March 31, 2005 1:25 PM
> To: [email-masked]; 'Paul Hoffman'; 'Bill Sommerfeld'; 
> 'Jari Arkko'
> Cc: [email-masked]
> 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
> 
> > 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.
> > 
> >  
> >

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 31 Mar 2005 10:49:52 -0800

> Because then you would need to keep track of too many lists of messages.

The number of messages you have to maintain is equal to the window size.
If you decide that you don't want to buffer more than 10 messages, then split
the window between normal IKE messages and mobike messages. Whether
you allocate all of the window for IKE or split between IKE and MOBIKE,
it does not alter the complexity. So, i don't know why maintaining two windows
complicate. 

-mohan

---

From: "Geoffrey Huang" <[email-masked]>
Date: Thu, 31 Mar 2005 11:17:12 -0800

> Sent: Thursday, March 31, 2005 10:48 AM
> To: 'Geoffrey Huang'; 'Paul Hoffman'; 'Bill Sommerfeld'; 'Jari Arkko'
> Cc: [email-masked]
> 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 
> > To: [email-masked]; 'Paul Hoffman'; 'Bill Sommerfeld'; 'Jari 
> > Arkko'
> > Cc: [email-masked]
> > 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
> > 
> > > > That sounds good. The question is: how many should we 
> suggest to 
> > > > reserve?
> > > > 
> > > > --Paul Hoffman, Director
> > > > --VPN Consortium