Subject: Re: [Mobike] issue 11 -- window size

From: Jari Arkko <[email-masked]>
Date: Mon, 09 May 2005 14:26:46 +0300

Hello folks,

We have had a lively discussion about this on the list.
We started by listing a couple of alternatives including
doing certain MOBIKE messages outside the window,
and requiring larger than 1 window sizes. Tero brought up
his proposal (see [1] and clarifications e.g. in [2]) which
can work under window size 1 while still fitting within
the regular IKEv2 message processing. Some discussion
was held on exactly how this can be integrated to NAT
traversal and potential future extensions.

My sense was that there were at least some persons who
felt that Tero's approach is good enough. I think Mohan
was the only one who had question marks
about this, e.g., why pick it over others and how well it
works with NATs. How do others who have not voiced
an opinion yet feel? Are there serious issues with Tero's
proposal? If not, we could just do what Tero proposed.

--Jari

[1] http://www.machshav.com/pipermail/mobike/2005-April/000730.html
[2] http://www.machshav.com/pipermail/mobike/2005-April/000752.html

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

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 9 May 2005 22:04:04 -0700

> 
> Repeating myself from IETF62, Tero's proposal (using the latest
> IKEv2 request as a path test message) works perfectly if the
> responder never uses the addresses from the IP header for
> anything else except transmitting the reply. All the cases
> where the IP header is used for something else require some 
> kind of special handling, and this complicates things.
> 
In my understanding, the new addresses is just used only
for the reply but i can see how it interacts badly with IKEv2 NAT-T.

> One example that I mentioned to Tero in Minneapolis...
> 
> - Current path (A1,B1) stops working, and the peers switch 
>   to (A2,B2). A is behind a NAT in both cases.
> 
> - After a while (A2,B2) still works (and continues working), but
>   the peers really prefer (A1,B1) because it's faster/cheaper/
>   whatever. So, A sends the last request using addresses (A1,B1) 
>   to see if it has become operational again.
> 
> - Suppose that direction A1->B1 works, but B1->A1 does not
>   (e.g. because of a malfunctioning middlebox or something; the
>   cause does not really matter). B receives the packet, and if
>   it hasn't seen it yet, processes it, sends reply, and (if it
>   implements the NAT-T "SHOULD" from IKEv2) moves all traffic to 
>   path (A1,B1). Which does not work.
> 
> - In MOPO-IKE, path test is a separate message primarily
>   because then it cannot interfere with anything else. Here, 
>   host A would not receive B's reply to the PATH_TEST 
>   message, and traffic would stay on path (A2,B2) which 
>   is working fine.
> 
If the window size is 1, you have to retransmit the last message with
a new address (discovered through PATH_TEST message in your case). 
If  "A" retransmits the message with new address (A1, B1), why does'nt B move all
traffic to path (A1, B1) ? How is this prevented in MOPO-IKE ?

-mohan

> Of course, there are several ways how this particular problem
> could be fixed. (Or we could define this as a feature rather
> than a problem :-)
> 
> IMHO going through all these special cases and ensuring that
> they're handled correctly is more work (and more complexity in
> the spec) than a separate path test message. But perhaps the
> difference in complexity is not that big, so if people are
> really interested in working on those special cases, we could
> go that route, too...
> 
> Best regards,
> Pasi
> 
> > -----Original Message-----
> > From: Jari Arkko
> > Sent: Monday, May 09, 2005 2:27 PM
> > To: Tero Kivinen
> > Cc: Mohan Parthasarathy; MOBIKE Mailing List
> > Subject: Re: [Mobike] issue 11 -- window size
> > 
> > 
> > Hello folks,
> >

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 10 May 2005 18:24:36 -0700

> 
> Tero Kivinen writes:
> 
> > Yes, I agree that doing probing of previously non-working 
> > addresses, which now have unidirectional connection, can cause 
> > the connection to loose packets in case there is NAT between both 
> > connections we are trying to use. So I suggest we do not try to do 
> > probing on that case, but simply start finding the working path only 
> > after we know there is problem with current path.
> 
> I think it is useful to allow path testing even when the current
> path is working, and the protocol should support doing this 
> without disrupting ongoing communication (which does not seem
> to be possible in your proposal).
> 
Yes, this is a useful feature that MOBIKE should provide.

> (E.g., suppose we have two interfaces, one very fast and cheap, 
> second one very slow and expensive. If the first one has a temporary 
> problem, and we switch to the second one, we want to switch back 
> when possible even if the second interface keeps on working forever.)
> 
I am wondering when the switch will happen. If we assume that the switch
will not happen when the IPsec connection is actively used (e.g. streaming services),
then Tero's proposal would still be okay because temporarily changing to a
non-workable address will not affect much. But i don't understand why having
a separate PATH_TEST message is such a big deal. I don't see additional
complexity. So, what is the issue with having a separate PATH_TEST message ?
Jari said it is simpler. I am not sure i understood that.

-mohan