issue 34 proposal

This is a suggestion for a potential resolution of issue 34.
First, it seems that issue 34 is really about two separate
problems:

   Part a: How do we survive NAT reboots? ESP vs. IKE update?
   Part b: Do we have a separate path test message or not?

For part a, we have discussed probing frequencies and hardware
issues. List discussion on the probing seems to converge to
the conclusion that IKE-based messages for this purpose would
be OK. I'm not sure if we have come to any conclusion on the
hardware/implementation problem issues: There's a difference
where IKE-based messaging does not need hardware support
for ESP address changes. On the other hand we're not quite
sure if lack of hardware support is an issue for the ESP-based
approach either -- hardware evolves while deployment of new
features is ongoing. And as we are talking about a special case
to begin with, it may not be critical to have this support in
all devices at all times.

For part b, we have discussed whether the separate message
is easier to describe or not, and whether the separate message
can be sent in cases where additional IKE messages would have
to be delayed due to the usual IKE processing rules (e.g., when
connectivity breaks during an already ongoing movement operation).
In the latter discussion, it seems that we came to the conclusion
that if this happens, the worst that can happen is delay of
one roundtrip.

Based on the above I'd like to suggest that we pick
IKE based messages for NAT reboot/change detection,
and IKE messages for the path testing. Comments?

I asked Pasi to write some text for this, see below.

2.X Changes in NAT Mappings

   IKEv2 performs Dead Peer Detection (DPD) if there has recently been
   only outgoing traffic on all of the SAs associated with the IKE_SA.

   In MOBIKE, these messages can also be used to detect if NAT
   mappings have changed (for example, if the keepalive internal is
   too long, or the NAT box is rebooted).  More specifically, if both
   peers support both this specification and NAT Traversal,
   NAT_DETECTION_*_IP payloads MAY be included in any INFORMATIONAL
   request; if the request includes them, the responder MUST also
   include them in the response (but no other action is taken, unless
   otherwise specified).

   When the original initiator is behind a NAT, it SHOULD include
   these payloads in DPD messages, and compare the received
   NAT_DETECTION_DESTINATION_IP payload with the value from the
   previous UPDATE_SA_ADDRESSES response (or the IKE_SA_INIT
   response).  If the values do not match, the IP address and/or port
   seen by the responder has changed, and the initiator SHOULD send
   UPDATE_SA_ADDRESSES as described in Section 2.3.

   When MOBIKE is in use, the host not behind a NAT SHOULD NOT use the
   dynamic updates specified in [IKEv2] Section 2.23 (where the peer
   address and port is updated from the last valid authenticated
   packet).  This ensures that both peers have a consistent view of
   when addresses are to be changed, and prevents conflicts between
   MOBIKE-originated updates and NAT-T dynamic updates.  It also means
   that an INFORMATIONAL exchange that does not contain
   UPDATE_SA_ADDRESSES does not cause any changes, allowing it to be
   used for, e.g., testing whether a particular path works.

(And remove Section 2.5 about separate PATH_TEST exchange.)