RE: issue 34 proposal

Although I have earlier supported the "dynamic updates"
approach, I'm starting to think that handling this with explicit
IKE-level messages might be easier.  Since we already send
the DPD messages anyway, allowing them to contain NAT_DETECTION 
payloads is very simple (and might be worth doing even if we 
chose dynamic updates, the two are not totally exclusive).

And if we do this, then there isn't that much need for a separate
path test message, so perhaps it's simpler to leave it out...

So I support your proposal on issue 34.

Best regards,
Pasi

> -----Original Message-----
> From: ext Jari Arkko
> Sent: Wednesday, September 07, 2005 1:05 PM
> To: [email protected]
> Subject: [Mobike] 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.)