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

Tero Kivinen wrote: 

> It is very simple to say in the MOBIKE protocol, that
> implementations MUST NOT do dynamical address update if MOBIKE
> extensions are enabled, i.e. they MUST always do address
> updates only when receiving CHANGE_PATH message in case MOBIKE
> extensions are enabled.
>
> That will take care of all the problems using normal IKEv2
> packet to test path.
>
<snip>
>
> > Note that if the responder has NAT Traversal enabled, it 
> > can update the addresses in both the IKE_SA and IPsec SAs 
> > as usual (if it implements the "SHOULD" from [IKEv2] 
> > Section 2.23.
>
> There is no reason for the other end to enable the SHOULD in 
> case the MOBIKE is used. We can simply say that it MUST NOT do 
> the dynamic address updates in case MOBIKE is enabled.

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

It seems that we have several possibilities here. Some
preliminary thoughts of what the alternatives might be (but
other alternatives might exist too):

Option 1: Existing IKEv2 NAT Traversal and its dynamic updates
(when using NAT-T, host outside NAT automatically updates the
address/port from any authenticated packet).

Option 2: Disable the NAT-T dynamic updates, and create a new
mechanism for handling NAT mapping changes in MOBIKE.

   Option 2a: Responder (outside NAT) could notify the initiator
   when it sees that the port changed, but wait for initiator's
   CHANGE_PATH message before updating anything.
 
   Option 2b: Initiator could send CHANGE_PATH messages all the
   time just in case the NAT mappings might have changed (even
   though from its point of view, nothing has changed).
  
   Option 2c: More alternatives certainly exist..

Option 3: Disable NAT-T dynamic updates, but don't specify any
alternatives for handling NAT mappings changes (==essentially
break when NAT mappings change).

I'm strongly for option 1 here (although it seems that we
probably need a separate path test message then). Option 3 
does not sound very attractive compared to 1, and at least 2a
would IMHO require rechartering the WG.

(The charter says "the WG shall NOT develop mechanisms for the
following functions: [..] IP address changes done by third
parties (NATs, firewalls etc). [..] MOBIKE handles IP address
changes initiated by one of the endpoints of the security
associations. NAT traversal handles other address changes.")

Best regards,
Pasi