| Newsgroups |
gmane.ietf.mobike |
| Message-ID |
<[email protected]> |
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