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

From: <[email-masked]>
Date: Mon, 9 May 2005 17:14:10 +0300

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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 10 May 2005 11:03:04 +0300

Hi Pasi,

>  path (A1,B1). Which does not work.
OK, I see the problem now. It looks like there are
sevaral subtasks in what we are trying to do:

  (i) test
 (ii) commit to particular set of addresses
(iii) manage unidirectional connectivity (#19)

Tero's model, as I understand it, appears to combine
both (i) and (ii) as well as disallow unidirectional
connectivity. In a sense his model is less flexible, but
at the same time simpler. A good tradeoff? Lets think
about it.

Anyway, presumably you could modify Tero's proposal
to separate (i) and (ii). The drawback in that is that
if there's a change in connectivity between initiating
(ii) and completing it, you have no possibility to send a
test message -- only a commit message. This is because
the model requires sequenced delivery of all messages.

But what exactly is the problem that results from this?
Presumably you wanted to commit to a particular
set of addresses. So the only reason why you might
want to start testing is that you don't get a response.
If you have just one alternative left, then there's no
issue -- switch to it, with commit, if you can. But if there
are multiple alternatives, then you might wish to test
which one to choose. Question: could you do this by
ordering the retransmissions of the commit message
in a proper way? (Or am I now in the area of trying to
fix the special cases that you Pasi were worried about?)

--Jari

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 10 May 2005 12:12:29 +0300

>   path (A1,B1). Which does not work.

Yes, IKEv2 NAT-T does not support unidirectional paths. That does not
mean that our MOBIKE protocol needs to do that.

On the other hand, I am not sure we want to support unidirectional
paths. I had a feeling we already somewhere decided that we do require
two-way connection between working addresses, i.e. we are not supposed
to support such thing.

The MOBIKE protocol can simply use path test and actual changes as a
separate message, there is no reason to do the changes based on the
other packets. On the other hand other packets can be used as a path
test message, as it does answer to the question "does this path
work?"

>   message, and traffic would stay on path (A2,B2) which 

If MOBIKE protocol uses separate N(MOVE TRAFFIC) then that thing can
only happen for very short time, and it will be fixed immediately
after that.

I.e. if we detect that A1<->B1 path works in both ways and we want to
move to it, and we send N(MOVE TRAFFIC). If the path A1<->B1 now
breaks so that A cannot get reply back, but B has already moved
traffic, then A will notice that it cannot get replies back so it
starts trying other addresses, and when it finds a working path the
traffic is then moved to that (either implicitly by B updating the
IPsec SAs for each address A tries, or explicitly by B ignoring
retransmissions of N(MOVE TRAFFIC) with different address, and A
noticing after exchange, that traffic got moved to wrong address, and
redoing the N(MOVE TRAFFIC)).

Same thing can happen in MOPO-IKE if the path happens to break between
path test and traffic move operations. 

> could be fixed. (Or we could define this as a feature rather

Yes, and as we are not talking about the actual protocol, we simply
need to agree here that those things can be solved. We are trying to
decide the higher level option, and if you find some fundamental
problem, which cannot be solved at all then we want to hear it now... 

> really interested in working on those special cases, we could

Most of the same special cases needs to be handled regardless weather
the path test is separate or not. We need to solve the thing what to
do for the ongoing exchange when the path breaks during it. We cannot
modify the packet anymore, and we must deliver it to the end, meaning
that we need to modify the outer header of that packet anyway, thus
same problems.

I haven't read the MOPO draft for a while, so I do not remember how
those issues were solved there. Perhaps I need to reread it now and
see how things are done there... 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 10 May 2005 14:29:34 +0300

> at the same time simpler. A good tradeoff? Lets think

The protocol in my model can be defined either to combine (i) and (ii)
or do them as separate steps. i think it might be better to do them
in separate steps.

On the other hand in my proposal all (ii) commit messages are also
always (i) test messages too, but not other way around.

(iii) I do not think we should try to work around with unidirectional
connectivity. 

> the model requires sequenced delivery of all messages.

But as each (ii) is also (i) message, the result of that will be that
you have done new test and have a new address pair that works, so you
can initiate (ii) again immediately and move traffic there. In the
mean time the traffic might be going to some other non-working
address, but that it was most likely going to non-working address
already before, as that is the reason why we started (ii), so no
difference there.

> which one to choose.

In my proposal you can test it with empty information exchange (i.e.
DPD). That will return new working pair of address. I had separate
N(MOVE TRAFFIC) notify which was used to move traffic. But as N(MOVE
TRAFFIC) is normal IKEv2 packet then it also acts as test packet.

> Question: could you do this by ordering the retransmissions of the
> commit message in a proper way? (Or am I now in the area of trying
> to fix the special cases that you Pasi were worried about?)

The protocol could periodicly or every time it notices change do path
test with all paths with normal DPD style packet. That would not do
any change in the MOBIKE state yet. When the working best path is
found then the protocol could move traffic to new address pair by
N(MOVE TRAFFIC) notify.

For IKEv2 NAT-T interaction you have also couple of options. Easiest
is simply say that NAT-T works as defined in the IKEv2, but the SHOULD
for implicit update is MUST, and if initiator detects that N(MOVE
TRAFFIC) did't go through with selected pair, and it needs to rever to
test path method, then it needs to do N(MOVE TRAFFIC) again with new
working path.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike