RE: issue 11 -- window size

Hello,

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.

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.

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
>