RE: Issue 34: Separate path test, handling changes in NAT mappings

[email protected] writes:
> > > Hmm... it seems the issue of a separate path test message
> > > vs. using normal informational exchange for path testing 
> > > depends a lot on how we handle changes in NAT mappings (if 
> > > e.g. NAT is rebooted or keepalive interval is too long).
> > 
> > Not really. The problem only occurs if we want to use the path
> > test to test previously broken path without affecting the
> > currect path and there is NAT-T between. If we use path test
> > only when the operational address pair has already broken down
> > then we do not need to modify dynamic address updates of the
> > NAT-T.
> 
> This was discussed already in May 2005... At least some people
> thought that it would be useful to allow path testing even when
> the current path is working (and without disrupting ongoing
> communication).

Yes, I know it was discussed earlier, but simply pointed it out here
to explain why we need to do things here like I explained. So now
people can really decide wheather they want that complication to the
protocol for that feature. 

> I'm not quite sure how important problem this is, but since the
> problem is already solved in IKEv2 NAT-T, I think we should have
> really good reasons for not using that solution. (Much better
> ones than "I didn't bother to implement that SHOULD in my
> product" or "Not invented here / We just like doing things
> differently").

I do not think it was solved in the IKEv2 NAT-T. If the IKEv2 NAT-T
would be ok, then there would be not need at all to MOBIKE, simply use
IKEv2 NAT-T all the time. We would loose the multihoming aspect and
would waste some bytes on packets, but it would work for the mobility
part.

I do not think the dynamic automatic updates are good for MOBIKE. I
want MOBIKE to be more secure than IKEv2 NAT-T, which means more
controlled way on changing paths on MOBIKE than in IKEv2 NAT-T. If we
also do the same thing on the NAT-T with MOBIKE, then we can get more
security for that part too.

If we only do updating of operational address pair on explicit notify,
then the attacker cannot take any packet and change the addresses of
packet to redirect the packets to some other address.

Instead attacker needs to first distrupt the normal processing of the
packets to get the initiator to do the DPD with address pair update
notify, before he can change the operational address pair, and in that
case it is also processed in the responder site as normal addres pair
updating, which means it is subject to the return routability checks
etc.

If we do use the dynamic automatic update of the IP address of the
IKEv2 NAT-T, then we do not do return routability checks, thus we do
not have as good protection against flooding attacks as we would have
in case of MOBIKE style address update. 

> If that's the case, wouldn't it be simpler to just use the 
> same mechanism (dynamic automatic updates) when NAT-T is
> used with and without MOBIKE?

Yes, it would be marginally simplier for the NAT-T case, but we add
more complexity for all other cases, by adding new protocol to be
implemented. And then we do not get the protection provided by the
MOBIKE. No return routability checks, no N(COOKIE2) etc.

I do not think we want to add new protocol to do path testing, as it
can be done without any extra effort inside the normal IKEv2 MOBIKE
processing. 

What are the benefits of the separate path tests? Can you list me
reasons why we need to have that?

My reasons why I do not want to have separate path test protocol is:

1) I do not want to add yet another extra protocol to same port as
   IKEv2 (we already have 4 there (IKEv1, IKEv2, UDP encapsulation,
   UDP encapsulation keepalives)). (It is not IKEv2 exchange, as it
   does not follow encryption, authentication, message-id, windowing
   etc specifications of the IKEv2).

2) Security implications of non-encrypted, non-authenticated protocol
   are not completely tought out (at least yet).

3) We have already existing code we can use inside the MOBIKE IKEv2
   implementations which can do the same thing. This code is needed to
   be there regardless wheater we have or have not separate path test
   protocol (i.e we need to be able to handle the situation when the
   path breaks down during the IKE negotiation, i.e. we must be able
   to retransmit the IKE packets to alternative addresses).

   This means that by reusing that code we can do the path test, with
   less added code implementations, which means fewer bugs. (The code
   that needs to be added is: disable the (probably not yet
   implemented) automatic dynamic updating of NAT-T address changes;
   add check to DPD that if we are behind NAT and MOBIKE is enabled
   add N(CHANGE_PATH) to the DPD message).
-- 
[email protected]