issue 34 proposal

Tero Kivinen <[email protected]>
Newsgroups gmane.ietf.mobike
Message-ID <[email protected]>
Jari Arkko writes:
> 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 am in favor of this approach... (as people already probably know :-)

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

Note, that original initiator can also save one round trip (and one
exchange) if he adds both NAT_DETECTION_*_IP and UPDATE_SA_ADDRESSES
notifies to the DPD messages. If the addresses have not changed then
the UPDATE_SA_ADDRESSES is no-op thus only wasting 8 bytes in the
DPD. If the addresses have changed because of the NAT mapping
disappearing, then it saves the one round trip and makes the recovery
faster.

I think it is already allowed in the protocol, as it does say that we
proces UPDATE_SA_ADDRESSES notification in any INFORMATIONAL exchange,
but it might be good to notify this possibility here too. 
-- 
[email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.