--------------------

Mohan Parthasarathy (2005-10-03):

- Section 4.4

     The initiator receives a NAT_DETECTION_DESTINATION_IP
     notification that does not match the previous UPDATE_SA_ADDRESSES
     response (see Section 4.7 for a more detailed description).

This does not work reliably when IKE rekeying happens which changes
the IKE SPIs.  The initiator is behind NAT, creates the IKE SA and
notes the down the NAT_DETECTION_DESTINATION_IP notification value
(hash of SPI, IP address and port). If rekeying happens sometime later
but never received a NAT_DETECTION_DESTINATION_IP or received one
before rekeying happened, then the hash may differ because the NAT
rebooted causing ports to change OR SPIs changed because of
rekeying. How do you tell the difference between the two ?  According
to section 4.7, the sender SHOULD send UPDATE_SA message. Though there
is no harm in sending one, this case should be explained somewhere..

--------------------

Jari Arkko (2005-10-03):

I think you are correct. I agree though that this does not cause
a serious problem.

--------------------

Pasi Eronen (2005-10-03):
https://www.machshav.com/pipermail/mobike/2005-October/001090.html

Hm... yes, this is true. Any suggestions what to do about this?
Would just mentioning this be sufficient? (It doesn't seem
to be a serious problem, especially since IKE_SA rekeying is
not done very frequently.)

--------------------

Mohan Parthasarathy (2005-10-03):
https://www.machshav.com/pipermail/mobike/2005-October/001094.html

> Hm... yes, this is true. Any suggestions what to do about this?
> Would just mentioning this be sufficient? (It doesn't seem
> to be a serious problem, especially since IKE_SA rekeying is
> not done very frequently.)
 
Do we really need this functionality ? Why does the initiator need to
know explicitly that the NAT mapping has changed ? The initiator
behind NAT sends the DPD always with UPDATE_SA_ADDRESS. It should fix
it automatically. If it does not, then the PATH is broken. Wouldn't
that work ?

--------------------

Jari Arkko (2005-10-23):
https://www.machshav.com/pipermail/mobike/2005-October/001170.html

Section 4.4

     The initiator receives a NAT_DETECTION_DESTINATION_IP
     notification that does not match the previous UPDATE_SA_ADDRESSES
     response (see Section 4.7 for a more detailed description).

=>

     The initiator receives a NAT_DETECTION_DESTINATION_IP
     notification with a value that does not match the value in a
     previous UPDATE_SA_ADDRESSES response (see Section 4.7
     for a more detailed description).

     Note that this may cause an extra address update when
     IKE rekeying is in progress, because the NAT_DETECTION_DESTINATION_IP
     notification only contains a hash of the address and some
     other values such as the SPIs which change upon IKE rekey.
     Such an extra address update is harmless, however.

--------------------

Pasi Eronen (2005-10-24):
https://www.machshav.com/pipermail/mobike/2005-October/001204.html

Probably the "Changes in NAT Mappings" section is a better place
for this text than 4.4. I rephrased it slightly as follows:

   Note that this approach to detecting NAT mapping changes may cause an
   extra address update when the IKE_SA is rekeyed.  This is because the
   NAT_DETECTION_DESTINATION_IP hash also includes the IKE SPIs, which
   change when performing rekeying.  This unnecessary update is
   harmless, however.

--------------------

Jari Arkko (2004-10-24):
https://www.machshav.com/pipermail/mobike/2005-October/001207.html

Ok.

--------------------

Mohan Parthasarathy (2005-10-25):
https://www.machshav.com/pipermail/mobike/2005-October/001210.html

I am okay with this. 

Note we are talking about "Changes in NAT mappings". Is it okay for an
implementation to implement just one of the two schemes

1) send NAT-D payloads in DPD messages, compare the response with the previou
   UPDATE_SA_ADDRESS response
2)  send NAT-D payloads in DPD messages with UPDATE_SA_ADDRESSES

--------------------

Pasi Eronen (2005-10-28):
https://www.machshav.com/pipermail/mobike/2005-October/001237.html

The spec allows the initiator to decide which way it wants to do, 
but doesn't require any particular method of choosing. Hardcoding
is obviously one valid way (but so are a configuration option
and dynamic selection based on some heuristic).

The responder will support both anyway (but doesn't really need 
additional code, since it cannot know whether a message is 
"DPD message" or something else).

--------------------