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

From: <[email-masked]>
Date: Tue, 10 May 2005 13:44:10 +0300

Tero Kivinen wrote:

> > - 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.
> 
> 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.

Yes, I also think we should not support unidirectional paths,
but there are two quite different ways we can do that:

1) treat unidirectional paths the same way as totally 
   dead paths: don't use them
2) assume that unidirectional paths never occur, and 
   possibly fail in weird ways if they do

IMHO we should do the first.

> 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?"

Not unless we change NAT-T a bit, because currently it can treat 
any authenticated packet as a change (rather than just test). 
MOPO-IKE's approach, using a separate PATH_TEST message that is
neither part of any IKE_SA nor authenticated solves works with 
current NAT-T behavior.

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

---

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

> IMHO we should do the first.

I agree in that. My proposal works fine even if there is
unidirectional path, it will not simply use them. During the path test
it might try to use them, but after the path test is finished it
either has found working bi-directional path or the connection has
been broken down. 

> neither part of any IKE_SA nor authenticated solves works with 

There is no need to change NAT-T unless we want to.

The initiator can detect the situation and it can fix it by sending
one more packet with proper source and destination address. The IKEv2
does not clarify if retransmissions of the previous packets are
considered as valid authenticated packets, and if the IP-addresses
needs to be updated for each of those, or only for the first.

Regardless what implementations do on that, we can simply fix the
situation by sending new N(MOVE TRAFFIC) exchange with proper address
pair.

Exactly same thing happens if the path happens to break when MOPO-IKE
is sending the address update packet, and path happens to break in the
middle of that exchange. 

On the other hand we do want to modify NAT-T a bit, at lest say that
the dynamically updating addresses is MUST, so we might want to
clarify this issue also.

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.

As the path information is going to expire very quickly anyways, I am
not sure how much probing different paths while the current path still
works is going to help. 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike