Re: issue 11 -- window size

> 
> 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,
> > 
> > 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 protected]
> > https://www.machshav.com/mailman/listinfo.cgi/mobike
> > 
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike